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ABSTRACT 


Development  of  SeaBase  Operations  has  brought  about  the  need 
for  Modeling  and  Simulation  (M&S)  analysis  of  prototypes 
like  the  Transformable  Craft  (T-craft)  as  a  SeaBase  Enablers 
(SBE)  .  The  uses  of  M&S  tools  for  the  modeling  of  new 
capabilities  have  been  problematic,  since  there  are  no 
standard  requirements  for  simulation  development.  The 
accreditation  process  of  M&S  tools  also  offers  no  guidance 
into  the  functionalities  of  simulations.  The  goal  of  this 
thesis  was  to  define  a  hierarchical  framework  of 
capabilities  for  evaluating  a  simulation  or  "suite  of 
simulations"  suitable  for  modeling  SBEs.  A  capability 
hierarchy  is  needed  to  enable  decision  makers  to  compare  end 
user  needs  with  M&S  tools'  abilities.  An  analysis  of 
alternatives  was  conducted  on  six  M&S  tools  to  develop  a 
capability  hierarchy.  The  three  top  level  capabilities  that 
were  defined  in  an  M&S  setting  were  Usability,  Flexibility , 
and  Scalability .  A  roll-up  method  was  then  used  to  evaluate 
three  time-step  and  three  next-event  based  models.  The  end 
result  of  the  comparisons  showed  that  a  "suite  of 
simulations"  was  more  capable  of  modeling  SBEs  than  a  single 
simulation.  The  results  provide  decision  makers  with  a 
standard  approach  to  define  user  needs  and  how  to  apply  them 
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I. 


INTRODUCTION 


All  models  are  wrong,  but  some  are  useful 

—Sergey  Arkhipenkov 

A.  BACKGROUND 

Modeling  and  Simulation  (M&S)  tools  typically  have  been 
designed  for  specific  purposes  but  often  are  used  for 
insight  into  completely  different  questions.  In  today's 
technologically  advanced  world,  there  has  been  relatively  no 
limit  to  the  capability  of  computer-based  simulation  and 
what  it  could  provide  to  understanding  an  event. 

This  study  focused  on  the  capabilities  of  M&S  tools  to 
represent  SeaBase  Enablers  (SBE)  by  conducting  an  analysis 
of  alternatives  of  computer-based  simulations.  The  context 
of  this  study  was  based  on  SeaBase  Operations  (SBO)  concept, 
being  developed  by  the  United  States  Navy,  which  extends 
from  a  concept  called  Sea  Power  21  that  advertises  power 
from  the  sea.  Seapower  is  the  concept  of  globally 
projecting  naval  presence  to  maintain  security  and  advancing 
the  national  interests  (CNO,  2007).  Facilitating  these 
naval  operations  at  sea  is  a  complex  naval  organization  that 
relies  heavily  on  logistical  support  ships  necessary  for 
sustainment.  The  SBE  concept  was  defined  as  the  logistical 
support  elements  that  interact  with  the  SBO  to  provide  cargo 
and  supplies  for  sustainment  operations. 

The  models  chosen  were  time-step  and  next-event  based 
models,  which  are  two  types  of  models  within  the 
constructive  category  of  M&S.  A  narrow  scope  of  Department 
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of  Defense  (DoD)  and  industrial  used  models  that  have  had 
application  in  SBE  modeling  are  listed  in  Table  1. 


Model  Common  Name 

Simulation  Category 

Integrated  Theater  Engagement  Model 

(ITEM) 

Defense  Threat  Reduction  Agency  in 

association  with  (I AW)  SAIC  Company 

/  Next-Event 

Naval  Simulation  System  (NSS) 

SPAWAR  I AW  Metron  Co.  /  Next-Event 

Map  Aware  Non-Uniform  Automata 

(MANA) 

New  Zealand' s  Defense  Technology 

Agency  /  Time-Step 

Pythagoras 

Marine  Corps  Warfighting  Lab  (MCWL) 

IAW  Northrop  Grumman  /  Time-Step 

Joint  Conflict  and  Tactical 

Simulation  (JCATS) 

Joint  Force  Command  (JFCOM)  Joint 

Warfare  Center  (JWC)  /  Next-Event 

Simkit 

Naval  Postgraduate  School  /  Next- 

Event 

EXTENDSim 

Imagine  That!  /  Next-Event 

Combat  Analysis  Tool  for  the  21st 

Century  (COMABT  XXI) 

TRAC  WSMR  IAW  MCCDC  OAD  /  Next- 

Event 

SimPy 

Source  Forge  Co.  /  Next-Event 

NetLOGO 

Connected  Mathematics  Co.  /  Next- 

Event 

Table  1.  M&S  Tools  Used  in  DoD  and  Industry  for  SBE 

Modeling . 


Current  modeling  of  the  SBE  is  use  of  NSS  by  the  System 
Engineering  Group  at  the  Naval  Postgraduate  School  (NPS)  to 
model  SBE  in  peacekeeping,  crisis,  and  stability  missions. 
SimPy  is  another  M&S  tool  being  used  by  Georgia  Tech 
University  to  model  SeaBase  concepts  and  determine 
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alternative  employment  of  SBE  for  scenarios  around  the  world 
when  based  at  different  debarkation  points. 


B.  SEAPOWER  21 

The  Strategy  for  Sea  Power  21  entails  joint  operational 
effectiveness  and  incorporates  SBO  and  Sea  Shield  operations 
(Projecting  Global  Defensive  Assurance)  to  make  a  unified 
front  called  Sea  Strike  (Projecting  Precise  and  Persistent 
Offensive  Power)  with  new  technology  that  must  be  ready  to 
support  it.  The  Chief  of  Naval  Operations  (CNO)  (2007)  has 
stated  that  the  Navy  must  maintain  an  ability  that  will 
reaffirm  "the  use  of  sea  power  to  influence  actions  and 
activities  at  sea  and  ashore"  (p.  8)  .  Thus,  operational 

focus  of  the  U.S.  Navy  has  shifted  from  traditional  warfare 
to  developing  SeaBase  concepts  and  sustained  operations  in 
forward  deployed  areas.  SBO  is  one  of  the  strategic  pillars 
supporting  operations  in  a  Naval  setting,  with  Sea  Power  21 
being  the  conceptual  wave  of  the  future.  Sea  Power  21  is 
derived  from  the  unified  maritime  strategy  of  the  CNO  to 
protect  the  American  way  of  life.  It  is  the  ability  of  the 
U.S.  Navy  to  be  globally  postured  around  the  world  to 
maintain  continued  operations  with  adequate  resources.  This 
includes  pre-positioned  capabilities,  joint  operations,  and 
decreased  reliance  on  infrastructure  (Flitter  &  Sintic, 
2009)  .  The  SBO  establishes  a  base  of  operations  for  U.S. 
military  forces  to  be  inserted  into  the  conflict  or  crisis 
(CNO,  2007) . 

SBO  enables  National  and  Naval  strategy  with  the 

ability  to  maintain  operational  sustainment.  SBO  roles  in 

crisis  relief  efforts  and  regional  conflict  have  evolved 

with  the  ever  changing  demands  of  the  world.  Contributions 
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to  allied  nations  have  been  closely  linked  to  the  ability  to 
maintain  the  sea  lanes  of  communication.  Relief  efforts  in 
crisis-stricken  countries  like  India  in  2007,  Aceh  Indonesia 
and  Sri  Lanka  in  2008,  Thailand  in  2008,  and  most  recently, 
Haiti  in  2010,  have  shown  the  versatility  of  the  U.S.  Navy 
and  the  U.S.  military  to  perform  operations  other  than 
warfare.  The  U.S.  government  has  made  it  a  priority  to  make 
humanitarian  and  relief  operations  just  as  important  as 
warfare  operations. 

According  to  the  Office  of  the  Under  Secretary  of 
Defense  for  Acquisition,  Technology,  and  Logistics 
(USDAT&L)  ,  SBO  are  enablers  of  Sea  Power  21  (CNO,  2007)  . 
SBO  require  development  of  new  capabilities  to  enable  its 
use  in  the  21st  century.  SBO  is  a  chain  of  interdependent 
operations  that  have  systematic  issues  with  current 
capabilities  for  sustainment.  The  recommended  capability 
for  development  is  for  a  long-range  heavy-lift  cargo  vessel 
that  is  able  to  handle  environmental  conditions.  Through 
industrial  and  academia  research,  the  SBE  is  being  formed 
into  that  capability  with  the  focus  being  to  fill  current 
technology  gaps. 

C.  SEABASE  ENABLER  PROTOTYPES 


One  way  of  maintaining  seapower  is  through  research  and 
development  of  new  technologies  in  naval  ships  that  can 
serve  as  SBE.  SBEs  are  projected  to  provide  rapid 
transportation  of  needed  cargo  and  materials  to  and  from  the 
SeaBase  to  debarkation  point.  The  Office  of  Naval  Research 
(ONR)  began  the  Innovative  Naval  Prototype  (INP)  program  in 
2006  to  refine  conceptual  ideas,  develop  technology,  and 


ultimately  manufacture  SBE 
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Military 


capabilities . 


industrial  companies  have  been  designing  a  new  amphibious 
craft  called  the  Transformable  Craft  (T-Craft)  to  meet  the 
SBE  needs . 

There  are  three  prototype  designs  in  competition  for 
contract  awards  by  ONR.  The  first  design  is  the  Alion, 
which  is  being  developed  by  Raytheon  in  conjunction  with 
Nichols  Bros  and  CDI  Marine.  The  second  design  is  Textron 
Marine,  being  developed  by  CDI  Marine  with  Naval  Surface 
Warfare  Center  Panama  City  Division,  Jacobs  Engineering, 
Littoral  Research  Group,  and  Mid-City  New  Orleans  (MiNO) 
Marine  Inc.  The  third  design  is  the  Umoe  Mandal,  designed 
by  the  Goodrich  EPP  in  association  with  Kiewit  Offshore 
Services,  Island  Engineering,  General  Atomics,  Ultra  Poly 
Inc.,  Griffon  Hovercraft  Group,  Applica  Inc.,  and 
Massachusetts  Institute  of  Technology  (MIT)  (Flitter  & 
Sintic,  2009) . 

1.  Transformable  Craft 

The  T-craft  is  an  amphibious  craft  being  designed  to 
fill  the  technology  capabilities  gap  in  SBO  and  server  as  a 
SBE.  There  are  technical  challenges  associated  with 
developing  prototypes  of  this  design:  minimal  manning  versus 
operational  requirement,  multi-mode  propulsion  systems, 
external  seals  for  bow  and  stern  and  retractable  hover 
shirts.  Along  with  technical  issues,  there  are  operational 
considerations  that  are  focused  on  placing  T-craft 
capabilities  in  future  operations.  The  real  question  is 
where  will  T-craft  fit  into  the  U.S.  military's  concept  of 
operations?  The  initial  deployment  vision  is  centered  on 
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worldwide  fast  response  to  crisis  missions,  followed  by 
combat  supply  missions.  Further  details  on  T-craft  missions 
will  be  explored  in  Chapter  V. 

2.  Industrial  Designs 

The  T-craft  prototype  designs  are  based  on  ONR 
capability  requirements  with  only  slight  differences.  The 
Textron  Marine  is  projected  to  have  an  open  bay  deck,  unlike 
the  other  two  prototypes,  which  have  closed  bays.  Deck 
space  varies,  with  the  Umoe  Mandal  having  6000  feet  (ft)2  to 
the  Textron  Marine  having  8000  square  feet  (ft)2.  One 
important  capability  consideration  with  the  development  of 
T-craft  is  the  limitation  on  landing  abilities.  T-craft 
hover  capability  is  projected  to  be  able  to  maneuver  onto 
shore  slopes  with  gradients  of  approximately  2  percent  or 
less.  All  M&S  tools  were  assumed  to  model  shore  landing 
site  with  less  than  2  percent  slopes  and  be  sufficient  for 
SBE  Scenarios.  Figure  1  depicts  the  three  T-craft 
prototypes . 


Proposed  Prototype  Designs  by  Industry. 
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Figure  1 . 


3. 


Initial  T-Craft  Analysis 


A  capstone  project  conducted  by  a  group  of  Systems 
Engineering  students  at  NPS  working  in  conjunction  with  ONR 
sponsored  funding  investigated  whether  the  T-craft  prototype 
was  a  suitable  SBE .  Their  research  performed  a  simplified 
Analysis  of  Alternatives  on  the  SBE  concept.  Their  results 
identified  key  stake  holders  that  contributed  to  the 
validation  of  the  capabilities  for  SBE.  Additionally,  these 
students  provided  insight  to  decision  makers  on  transport 
capabilities  and  benefits  to  the  SeaBase.  Lastly,  their 
project  gave  technical  recommendations  to  ONR  on  where  the 
T-craft  program  should  proceed  (Flitter  &  Sintic,  2009)  . 

D.  T-CRAFT  DEVELOPMENT 

T-craft  is  being  designed  to  fill  the  gaps  in  current 
SBE  capabilities.  ONR  defined  capabilities  for  the  T-craft 
are : 

1.  2500  nm  range  maintaining  fuel  efficiency  (20kts) . 

2.  Operate  in  sea  state  of  4  at  high  speeds,  with  or 
without  cargo. 

3.  Maintain  a  maximum  speed  of  40+  knots  and  a  500  nm 
combat  range . 

4.  Amphibious  mode  for  landing  on  the  beach. 

5.  Freely  convert  between  modes  at  sea. 

6.  Transfer  cargo  to  SBO  units  and  beach  landings 
sites . 

7.  Carry  500  Long  Tons  (LT)  of  Cargo  (ONR,  2005) . 
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ONR  (2005)  began  developing  the  T-craft  "Game  Changing" 
capability  with  the  issuance  of  the  Broad  Agency 
Announcement  (BAA)  05-020  and  a  call  for  an  INP  for  SBE 
operations.  The  ideal  use  for  T-craft  is  in  a  high-speed 
sealift  scenario  less  than  300  nautical  miles  (nm)  from  the 
shore  in  no  more  than  sea  state  4  and  with  a  payload  of  500 
long  tons.  BAA  focused  on  industrial  competition  of 
designing  T-craft  with  the  ultimate  desire  to  acquire  a 
material  solution  to  current  gaps  in  SBE.  In  each  Phase  of 
development,  ONR  has  pointed  out  the  need  to  use  M&S  tools 
in  analysis  and  evaluation  of  T-craft  capabilities  in  a  cost 
reduction  effort.  The  final  goal  is  to  develop  the  concept, 
build,  test,  and  demonstrate  the  concept's  ability  in  given 
scenario  settings. 

There  are  four  scenario  requirements  for  which  T-craft 
is  being  developed:  Peacekeeping  and  Peace  Enforcement, 
Regional  Crisis  Intervention,  Security  and  Stability 
Operations,  and  Major  Theater  War.  These  requirements  were 
the  basis  for  scenario  development  in  this  study.  The 
scenarios  were  based  on  a  possible  North  Korean  threat  to 
the  South  Korea  peninsula.  The  area  of  SBOs  was  based  in 
the  Sea  of  Japan  regional  layout.  The  geography  allowed  for 
a  logistic  hub  to  be  within  2500  nm  of  the  SBO  and  that 
could  vary  in  distance  from  the  shore  line.  The  scenario 
was  designed  with  two  phases:  Basic  and  Advanced.  The  Basic 
Scenario  was  a  non-opposed  scenario  similar  to  a  regional 
crisis  intervention.  The  Advanced  Scenario  added  onto  the 
Basic  Scenario  hostile  and  escort  forces  in  the  SBO  area. 
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E.  MODELING  &  SIMULATION 

This  research  focused  on  M&S  tools'  ability  to  allow 
for  visualization  and  comprehension  of  the  SBE  Scenario. 
The  Validation,  Verification,  &  Accreditation  (W&A)  process 
requires  that  M&S  tools  be  analyzed  for  correctness  and 
usefulness.  This  process  will  be  described  in  Chapter  II. 
Further  research  could  be  conducted  to  determine  the  general 
capabilities  of  a  Federate  of  simulations  for  modeling  of  a 
SBE  concept.  The  subjective  analysis  of  a  group  of 
simulations  for  SBE  Scenario  was  the  main  objective  of  this 
thesis . 

There  are  seven  M&S  Domains  that  cover  M&S  within  the 
DoD.  In  this  thesis,  four  domains  were  used  to  define  the 
capabilities  of  a  simulation  of  the  SBE:  Acquisition, 
Planning,  Test  &  Evaluation,  and  Analysis.  The  advantage  of 
using  these  domain  fields  was  to  narrow  the  scope  of  the  M&S 
Domain  space  for  developing  technology  like  the  SBE.  The 
three  capabilities  that  can  be  derived  from  these  domains 
are  usability,  flexibility,  and  scalability.  These 
capabilities  were  designed  to  ultimately  provide  decision 
makers  with  adequate  information  on  M&S  tools  to  apply 
throughout  the  life  cycle  of  the  SBE.  Constructive-based 
M&S  tools  are  poised  for  the  development  of  scenarios  to 
enable  analysis  with  time-step  and  next-event  based  models. 

1 .  DoD  M&S  Community  Domains 

The  goal  of  this  thesis  was  to  define  the  needs  of  SBE 
as  they  apply  to  M&S.  A  capability  hierarchy  framework  was 
used  to  translate  the  SBE  needs  into  listing  of 
functionalities  for  a  simulation  or  a  "suite  of  simulations" 
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to  be  evaluated.  The  purpose  was  to  apply  the  framework 
broadly  across  the  M&S  solution  trade  space  for  SBE 
modeling.  Ultimately,  the  Systems  Engineering  approach  used 
was  to  define  a  process  to  evaluate  the  contribution 
simulations  may  have  on  SBE. 

There  are  seven  domains  in  M&S:  Acquisition,  Analysis, 
Planning,  Testing,  Training,  Experimentation,  and 
intelligence.  These  domains  are  a  way  for  the  DoD  to  manage 
and  shape  M&S  tools  for  practical  use.  Below,  the  first 
four  domains  and  how  each  pertains  to  the  SBE  are  defined. 
The  last  three  domains  were  not  discussed  in  this  thesis 
because  the  scope  was  to  address  M&S  tools  that  contribute 
to  the  development  of  an  INP.  Training,  Experimentation  and 
Intelligence  pertain  to  operational  considerations  and  post 
production  (DoD,  2009)  . 

First,  Acquisition  is  the  overall  process  of  material 
solutions  in  the  cumulative  joint  capabilities  of  the  U.S. 
military.  There  are  two  options  in  acquisition:  (1) 
Material  solutions,  which  are  the  development  of  new 
technologies  for  capability  gaps,  and  (2)  Documentation 
solutions,  which  are  the  development  of  doctrine  to  adjust 
for  operational  deficiencies.  M&S  can  provide  assistance  in 
the  development  of  a  SBE  throughout  the  T-craft  life  cycle 
(DoD,  2009)  . 

Second,  Analysis  is  the  ability  to  understand  how  a 
process  or  situations  potentially  unfolds  in  the  future.  In 
other  words.  Analysis  can  provide  proof  of  concepts  for  SBO 
in  forward  deployed  areas.  M&S  gives  researchers  the 
ability  to  model  operational  considerations  in  an  effort  to 
develop  systems  with  well  rounded  capabilities  (DoD,  2009)  . 
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Third,  Planning  is  a  stage  for  developing  systems 
tactics  and  strategy  for  use  in  military  operations.  The 
SBE  is  new  concept  that  is  going  through  extensive  research 
in  interoperability  and  capability  limitations.  Planning 
can  identify  key  performance  parameters  in  a  SBE  by 
examining  situational  reguirements  (DoD,  2009)  . 

Fourth,  Testing  is  the  opportunity  to  stress  systems  in 
virtual  and  real  environments  to  give  the  warfighters 
advanced  capabilities.  M&S  can  stress  systems  to  the 
maximum  limits  in  a  virtual  environment  allowing  for  a 
spectrum  of  information  to  be  gathered  (DoD,  2009) . 


2 .  M&S  Capabilities  Derivation 

The  M&S  domains  described  above  encompass  three  aspects 
that  a  simulation  should  possess  to  model  a  SBE,  and  these 
are  Usability,  Flexibility,  and  Scalability.  Usability 
seems  to  relate  to  interoperability  issues  in  a  joint 
environment  where  new  technology  must  be  able  to  interact 
and/or  support  other  service  functions.  Flexibility  seems 
to  directly  reflect  the  versatility  of  new  technology  to 
evolve  and  be  sustainable  in  an  ever  changing  environment. 
Scalability  seems  to  be  associated  with  realistic  goals  of 
mass  production  and  survivability  in  multiple  environments. 

3 .  Simulation  Categories 

There  are  several  types  of  simulation  that  are  used  for 
modeling  and  analysis.  The  three  M&S  types  that  were 
associated  with  this  study  were  next-event,  time-step,  and 
autonomous  agent-based  modeling.  Time-step  based  models  use 
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equal  time-steps  between  processing  functions  of  events  to 
advance  the  simulation.  Next-event  based  models  process 
each  event  in  a  scenario  that  occurs  with  no  regard  to  a 
regular  review  of  simulation  status.  Agent-based  models  are 
centered  on  offering  attribute  adjusted  abilities  to  the 
user  for  more  robust  actions. 

These  three  types  of  M&S  tools  were  examined  across  the 
SBE  missions.  The  first  of  those  missions  entail  high-level 
operational  missions  like  peace  keeping  and  were  utilized 
for  modeling  a  Basic  Scenario.  The  Basic  Scenario  involved 
relief  efforts  of  transporting  humanitarian  aid  directly  to 
shore  sites.  The  second  mission  was  regional  conflict 
within  hostile  waters  surrounding  areas  of  SBO,  which  were 
used  to  model  an  Advanced  Scenario. 

Evaluation  of  M&S  tools  in  time-step  and  next-event 
based  modeling  assisted  in  determining  the  capability 
hierarchy.  Time-step  and  next-event  based  models  are  key 
types  of  M&S  tools  in  the  constructive  simulation  category 
that  are  used  in  the  DoD.  Table  2  presents  the  flow  of  this 
thesis  from  capability  generations  to  determining  a  trade 
space  of  alternatives  for  a  simulation  or  "suite  of 
simulations"  for  SBE  M&S.  The  M&S  tools  for  this  research 
are  delineated  in  Chapter  III. 
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Chapter  Title 

I  Introduction  into  SeaBase  Enablers 

II  Capabilities  Generation  based  on  M&S  Domains 

III  Possible  Solutions  for  M&S  of  SBE  Scenarios 

IV  Capability  Hierarchy  definition 

V  Simulation  Modeling  of  the  SBE 

VI  Results  Analysis  of  M&S 

VII  Capability  Evaluation  of  M&S  tools 
VIII  Simulation  Comparison  of  M&S  tools 

IX  Conclusion 
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II.  CAPABILITIES  GENERATION 


The  concept  of  defining  a  set  of  capabilities  for  M&S 
programs  evolved  from  the  idea  of  using  several  modeling 
tools  together  for  SBE  analysis  and  testing.  The  questions 
became,  which  M&S  tools  were  to  be  used  and  what 
capabilities  should  they  possess?  It  was  clear  that  any  M&S 
tool  used  in  this  research  must  be  accredited  to  show  that 
results  from  SBE  analysis  were  valid.  This  lead  to  the  DoD 
acquisition  system  that  offers  the  most  insight  into  M&S 
capabilities  based  on  the  fact  that  there  are  seven  M&S 
domains  created  to  shape  the  development  of  M&S  tools.  This 
chapter  addresses  how  the  capability  hierarchy  was  generated 
from  the  established  M&S  domains  areas  and  their  uses  to 
define  a  basic  set  of  functionalities  that  were  later 
complied  together  in  a  framework  to  evaluate  the  capability 
of  an  M&S  tool. 

A.  VALIDATION,  VERIFICATION,  &  ACCREDITATION 

Use  of  M&S  in  DoD  is  regulated  by  the  W&A  process. 
Decision  making  agencies  like  the  Defense  Planning  and  Joint 
Requirements  Oversight  Council  (JROC)  utilize  M&S  for 
specific  purposes  based  on  M&S  tools  capabilities. 
Currently,  there  is  not  a  standard  for  all  simulations 
because  W&A  requirements  limit  on  the  scope  of  models  to  a 
single  or  narrow  purpose  (DoD,  2003) .  The  capabilities 
hierarchy  can  allow  for  M&S  developers  working  with  SBE  to 
be  aware  of  user  (DoD)  needs  and  provide  more  functionality 
in  M&S  tools. 
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Developing  simulation  standards  is  important  because  of 
the  impact  M&S  has  at  all  levels  of  DoD  decision  making  in 
the  life  cycle.  The  capability  hierarchy  that  was  proposed 
in  this  study  attempted  to  identify  standards  needed  to 
model  SBE  by  grouping  a  set  of  functionalities  together  in 
an  evaluation  hierarchy.  Functionality  refers  to  a  single 
method  within  an  M&S  tool  that  is  used  to  enable  the  user  to 
manipulate  the  model  or  simulation.  The  definition  of  a 
hierarchy  was  an  attempt  to  increase  the  reusability  of  M&S 
tools  while  simultaneously  reducing  ad  hoc  program 
combinations  that  are  being  used  to  fill  gaps  in  DoD  M&S. 
The  capability  hierarchy  can  allow  for  M&S  developers 
working  with  SBE  to  be  aware  of  user  (DoD)  needs  and  provide 
more  functionality  in  M&S  tools.  The  functionalities  were 
directly  related  to  Verification,  Validation,  and 
Accreditation  (W&A)  along  with  the  Defense  Standardization 
Program  (DSP) . 

The  M&S  Coordination  Office  (MSCO)  promulgated  in  2000, 
operating  procedures  for  simulation  developers  on  standard 
methodologies,  programming  practices,  and  data  processing 
with  no  mention  of  simulation  reguirements  or  potential 
capabilities.  These  requirements  were  not  stated  and  left 
for  developers  to  interpret  end  user  and  stakeholder  needs. 
Defining  capabilities  required  to  model  a  SBE  may  hopefully 
aid  in  the  development  of  M&S  tools  specifically  for  SBE, 
with  emphasis  on  modeling  T-craft.  The  W&A  process  was  put 
in  place  to  govern  simulation  products  and  ensure  that  there 
was  quality  control  that  matched  user's  needs  with  results. 
The  W&A  process  seems  to  have  led  to  specific  tools  for 
specific  needs,  which  has  limited  the  use  of  M&S  tools  in 
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the  DoD.  Providing  a  list  of  general  capabilities  that  are 
reguired  by  the  DoD  to  be  present  in  M&S  tools  may  increase 
their  uses  in  decision  making. 

B.  LINKS  TO  M&S  DOMAINS 

The  purpose  of  M&S  in  DoD  has  always  been  to  accomplish 
requirements  with  less  money,  time,  and  loss  of  life.  M&S 
offers  decision  makers,  developers,  and  warfighters  the 
ability  to  experiment  with  ideas  without  the  risk  associated 
with  real-world  experimentation.  Users  of  M&S  are  important 
to  the  development  of  tools  that  are  used  in  the  DoD 
communities.  Given  that  there  are  defined  community  domains 
for  M&S  within  DoD,  the  link  between  those  domains  and  a 
capability  hierarchy  should  be  self-evident.  The 
characteristics  of  M&S  domains  lead  themselves  to  be 
interpreted  in  a  way  to  suggest  that  M&S  tools  need  to  be 
usable,  flexible,  and  scalable  as  introduced  in  Chapter  I. 
Four  of  the  seven  DoD  Communities  are  steeped  in  M&S 
application  of  developing  technology  and  material  solutions— 
Acquisition,  Analysis,  Planning,  and  Test  &  Evaluation.  The 
remaining  three.  Training,  Experimentation,  and  Intelligence 
tend  to  be  directed  at  operational  considerations  post 
production  phases.  Acquisition  is  the  overarching  domain, 
where  Analysis,  Planning,  and  Test  &  Evaluation  begin  to 
narrow  the  scope  of  M&S  applications.  These  domains  provide 
data  and  understanding  of  systems  for  further  development. 
The  derivations  of  M&S  requirements  from  these  communities 
provide  an  essential  framework  for  defining  a  capability 
hierarchy.  A  description  of  each  of  these  communities 
follows,  along  with  the  ways  in  which  a  capability  hierarchy 
would  be  useful  for  that  domain. 
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A  New  Approach  for  Managing 
DoD  Modeling  and  Simulation  (M&S) 


New  M&S  Management  Structure  Organized  by  Communities. 
Designed  to  Support  &  Integrate  M&S  Activities  across  the  Department. 

Led  by  a  1  to  2  Star  M&S  Steering  Committee  (M&S  SC)  to  provide  governance. 


Analysis 

PA&E 

&JS 


Planning 

JS 

&  Policy 

I  \ 


Testing 

DOT&E 

&AT&L 

:7=r 


Training 

P&R 


Experimentation 


Common  and  Cross-Cutting  M&S  Tools 


Common  and  Cross-Cutting  M&S  Data 


Common  and  Cross-Cutting  M&S  Services 


Components 

OSD,  Joint  Staff,  CQCOMs,  Services 


Goal:  Establish  corporate  M&S  management  to  address  DoD  goals: 
Leads/guides/shepherds  the  $Bs  in  DoD  M&S  investments;  adds  value 
thru  metrics  &  ROI-driven  priorities;  and  seeks  to  provide  transparency. 


Figure  2 . 


M&S  Domain  Management  Diagram  (From  MSCO, 
2007) . 


1.  Acquisition 

The  first  community  acquisition  is  at  the  heart  of 
major  developmental  concepts  that  govern  the  progress  of  the 
concept's  evaluation  from  birth  to  death,  which  is  referred 
to  as  the  life  cycle.  M&S  is  rooted  in  initial  phases  of 
system  life  cycles  because  of  the  potential  reduction  in 
time,  risk,  and  cost  it  offers.  As  noted  in  the  Office  of 
Secretary  of  Defense  report  (1997),  The  Study  on  the 
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Effectiveness  of  M&S  in  the  Weapons  System  Acquisition 
Process,  M&S  can  be  used  to  integrate  acquisition  functions 
like  design,  manufacturing,  and  requirements  together.  M&S 
tools  can  contribute  to  the  development  of  actual  prototypes 
of  T-craft  by  modeling  capabilities  and  testing  them  in 
extreme  conditions.  The  complexity  of  the  SBE  concept  lends 
itself  to  use  of  M&S  to  integrate  physical  research  with 
operational  tactics  and  joint  effectiveness.  Defining  the 
M&S  capabilities  based  on  the  process  can  assists  in  system 
acquisition  of  SBE  by  affecting  multiple  aspects  of  the  time 
delay  in  reaching  for  the  warfighters. 

2 .  Analysis 

The  Program  Analysis  and  Evaluation  (PA&E)  department 
within  the  Office  of  the  Secretary  of  Defense  (OSD)  is 
tasked  with  breaking  acquisition  projects  in  smaller 
understandable  parts.  This  basic  concept  is  the  core  of  DoD 
acquisition  analysis  and  how  it  was  applied  in  this 
research.  The  analysis  of  SBE  effectiveness  in  situations 
provides  insight  to  decision  making  on  the  future  of  systems 
and  in  how  to  further  develop  the  programs.  This  goal  is 
accomplished  by  collecting  data  on  cargo  transfer  rates  and 
amounts,  transit  times  in  a  given  environment,  and 
survivability  rates  with  varying  defensives.  M&S  tools  used 
for  analysis  should  be  able  to  provide  basic  information  on 
systems  by  performing  statistical  analysis  on  simulations 
iterations.  They  are  also  associated  with  exploration  of 
the  solution  space  SBE  occupies.  This  method  uses  the 
trends  that  models  display  in  M&S  environments  to  develop  a 
common  performance  measurement.  Operators  are  involved  at 
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all  levels  of  the  analysis  process;  therefore,  usability  in 
the  capability  hierarchy  is  important  in  M&S. 

3 .  Planning 

Planning  has  many  different  roles  in  system 
development.  The  first  role  is  production  factors  like 
manufacturing  schedules  that  affect  the  delivery  of  systems. 
The  second  role  is  logistical  needs  for  operating  forces. 
Lastly,  operational  planning  plays  a  major  role  in 
determining  the  requirements  for  systems  uses.  The 

requirements  are  wrapped  within  the  capability  of  M&S  tools 
to  model  and  simulate  planning  elements  that  affect  SBE 
deployment.  M&S  can  integrate  production  elements  into  the 
planning  process.  A  driving  factor  is  measuring  flexibility 
in  M&S  tools  used  for  planning  SBE  craft  capabilities  and  in 
its  use  within  military  applications.  Thus,  flexibility  is 
a  capability  crucial  to  planning. 

4.  Test  &  Evaluation 

The  office  of  the  Director  of  Operational  Test  and 
Evaluation  (DOT&E)  is  responsible  for  prescribing  policy  of 
Testing  and  Evaluation  (T&E)  in  the  DoD.  T&E  is  used  to 
measure  prototype  status  and  determine  when  systems  are 
ready  for  full  rate  production.  T&E  is  important  in  system 
development  in  determining  capabilities  achievement.  M&S 
can  greatly  assists  in  this  process  by  simulating  models  of 
systems  in  virtual  environment.  M&S  may  not  complete 
validate  their  effectiveness,  but  can  make  considerable 
steps  towards  evaluating  measures  of  effectiveness.  M&S 
should  be  used  throughout  the  development  of  SBE,  as  well 
with  T&E  craft  performance. 
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Dividing  industry  from  DoD  is  the  fact  that  commercial 
M&S  is  not  regulated.  Industry's  use  of  M&S  can  be 
dramatically  different  than  DoD  at  times,  even  more  of  a 
reason  to  standardize  the  capabilities  of  M&S  for  use  with 
military  concepts.  M&S,  on  the  other  hand,  must  be  flexible 
enough  to  handle  extreme  situations  that  are  required  in  a 
testing  environment  and  that  are  where  the  hierarchy  is 
limited  in  its  application.  Standards  are  not  all 

encompassing  and  some  amount  of  non-standards  can  be 
beneficial . 

C.  ACQUISITION  FRAMEWORK 

The  three  capabilities  derived  in  this  study  overlap 
multiple  M&S  domains.  Usability  is  essential  to  Analysis 
but  is  less  critical  in  planning  and  testing.  Conversely, 
flexibility  is  important  in  planning  but  less  in  Analysis. 
Scalability  is  no  different  and  is  grouped  into  the 
acquisition  system,  but  it  is  more  involved  in  planning  and 
analysis  by  focusing  on  large  number  high  fidelity  unit 
operations.  Figure  3  illustrates  the  relationship  between 
M&S  domains  and  the  upper  levels  of  the  capability 
hierarchy . 
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Acquisition 


Figure  3.  Capabilities  Hierarchy  Links  to  M&S  Domains. 
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III.  POSSIBLE  SOLUTIONS 


This  chapter  discusses  the  constructive-based  M&S  tools 
that  are  contained  in  the  SBE  M&S  possible  solutions.  The 
solution  space  for  modeling  a  SBE,  encompasses  a  wide 
variety  of  M&S  tools  and  presents  a  challenge  to  selection. 
Listings  of  M&S  tools  that  have  the  capability  of  modeling  a 
SBE  Scenario  are  identified  to  help  focus  research  efforts. 
There  were  three  time-step  based  models  and  three  next-event 
based  models  selected  for  evaluation  of  capabilities.  This 
chapter  was  designed  to  identify  and  briefly  introduce  the 
selected  M&S  tools  used  for  modeling  an  SBE  Scenario.  Table 
3  displays  the  six  M&S  tools  selected  and  its  corresponding 
information . 


M&S  Tool 

Version 

Joint  Conflict  and  Tactical 

Simulation  (JCATS) 

Version  8 

Map  Aware  Non  Uniform  Automata 

(MANA) 

Version  4.04.1 

Pythagoras 

Version  2.1.0 

Naval  Simulation  System  (NSS) 

Version  3.4.1  (Beta) 

Simkit  API 

Version  1.3.8 

Arena  Simulation  Software 

Version  12.0 

Table  3.  M&S  Selection  Information. 
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A. 


M&S  CATEGORIES 


There  are  two  classical  ways  to  study  a  system: 
experiment  with  the  actual  system  or  with  a  model  of  the 
system.  This  study  utilized  the  latter  approach  on  the  SBE 
concept  to  determine  a  basic  capability  hierarchy.  All 
models  are  a  part  of  the  live,  virtual,  or  constructive 
taxonomy.  This  taxonomy  has  varying  levels  of  human 
interface  with  different  types  of  simulations.  The  first 
category  is  a  live  simulation  that  has  actual  operators 
interacting  with  real  systems  in  a  real  environment.  The 
second  category  is  virtual  simulation,  which  differs  from  a 
live  simulation  by  the  fact  the  systems  are  simulated  and 
there  is  a  human-in-the-loop .  The  third  type,  constructive 
simulation,  is  a  man-made  model  that  executes  with  simulated 
operators  and  simulated  systems  (DoD,  1998) .  This  research 
focused  on  the  use  of  constructive  models  in  the  DoD  and 
industry . 

1.  Constructive  Models 

DoD  defines  a  constructive  based  model  as  one  in  which 
users  operate  and  provide  inputs  to  the  simulation  scenario 
where  the  adjudication  is  determined  strictly  by  the 
algorithms  coded  into  the  program  (DoD,  1998) .  All 
simulations  used  for  comparison  were  within  the  constructive 
simulation  trade  space.  In  this  thesis,  six  different 
simulations  were  chosen  to  give  a  clear  representation  of 
two  separate  types  of  simulation,  time-step  and  next-event 
based  models.  These  two  types  shared  autonomous  and  non- 
autonomous  agent  entities  qualities.  Figure  4  depicts  the 
relationship  between  the  two  types. 


Constructive 


Time  Step 


Next  Event 


Agent 


Figure  4.  M&S  Space  for  SBE  Modeling, 


According  to  Law  and  Kelton  (2000) ,  there  are  three 
dimensions  to  classify  M&S  tools.  The  first  dimension  is  a 
dynamic  model  that  changes  over  time  to  allow  for 
interaction  of  the  simulation  in  a  SeaBase  environment.  The 
second  is  a  stochastic  model  that  provides  random  inputs  to 
produce  a  realistic  capability.  The  last  is  the  capability 
of  the  simulation  to  take  discrete  time-steps  for  analysis 
of  a  single  event  to  observe  interactions  of  the  model. 

There  is  no  one  single  program  to  simulate  the  SBE 
concept  that  incorporates  the  three  dimensions.  When  used 
together,  the  three  types  of  simulation  are  a  possible 
solution  that  can  provide  information  on  one  or  all  Measures 
of  Performance  (MOP)  of  the  SBE  Scenario  that  the  U.S.  Navy 
has  defined  as  apart  of  the  Sea  Power  21  concept.  The 
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hierarchy  of  capabilities  was  used  to  determine  the  level  at 
which  a  tool  could  be  suitable  to  model  and  simulate  a  SBE . 

2 .  Autonomous  Agent  Based  Models 

An  Autonomous  Agent-Based  Modeling  (AABM)  was  defined 
in  this  study  as  a  program  that  makes  use  of  personal 
attributes  to  govern  the  actions  of  simulated  models. 
Programs  are  created  to  have  individual  entities  act  in  a 
common  way  to  make  autonomous  decisions  based  on  a  set  of 
organized  rules.  According  to  Bonabeau  (2002),  there  are 
three  benefits  to  AABM  that  may  prove  to  be  an  important 
factor  when  under  evaluation  for  SBE  modeling.  The  first 
was  the  ability  of  AABM  to  interact  with  the  environment  as 
the  scenario  unfolds  and  make  decisions  not  based  on 
probabilities.  This  benefit  will  make  the  AABM  highly 
usable  in  SBE  scenarios.  The  next  was  the  flexibility  of 
the  agents  to  behave  like  live  operators  and  be  easily 
modeled  into  the  scenario.  The  third  was  the  resolution 
control  of  AABM  being  able  to  adjust  force  levels,  making 
them  scalable. 

There  are  several  AABM  programs  that  are  available 
commercially  or  open  source  that  can  be  useful  to  decision 
makers.  The  two  AABMs  used  in  this  study  were  New  Zealand's 
Defense  Technology  Agency  (DTA)  Map  Aware  Non-Uniform 
Automata  (MANA)  ,  and  dual  development  by  the  U.S.  Marine 
Corps  and  Northrop  Grumman  on  Pythagoras  Simulator,  an 
agent-based  model.  The  development  of  AABM  has  produced 
tools  that  can  provide  analysts  the  capability  of 
experimenting  with  scenarios.  Agent  attributes  are 
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integrated  into  the  various  simulations  and  used  to  create 
agent  actions  that  are  indicative  of  real  motion  by  real 
players . 

B.  TIME -STEP  BASED  MODELS 

Time-Step  Based  Models  (TSBM) ,  or  continuous-based 
models,  are  designed  to  handle  the  propagation  of  predicted 
agent  action  changes  over  infinite  time  increments. 
Continuous-based  simulations  are  represented  by  the  changing 
of  state  variable  with  respect  to  time  (Gordon,  1978) .  TSBM 
used  in  problem-solving  situations  with  high  resolution 
scenarios  should  provided  strong  analysis  tools.  TSBM  have 
also  been  useful  in  enabling  the  modeling  of  dynamic 
phenomena  that  autonomous  agent-based  simulations  typically 
model.  The  complexity  of  the  simulation'’ s  functionalities 
introduces  many  issues  that  are  directly  related  to 
simulation  capabilities.  For  example,  the  larger  number  of 
entities  in  a  model  may  cause  the  computational  times  to 
increase . 

The  three  TSBM  were  Lawrence  Livermore  National 
Laboratory's  Joint  Conflict  and  Tactical  Simulation  ( JCATS) , 
MANA,  and  Pythagoras.  Each  is  posed  for  the  T-craft 
scenario  and  provided  insight  into  the  survivability  of 
units  in  a  hostile  environment.  JCATS  was  created  with 
detailed  physics  model  for  engagement  and  motion  through 
water,  where  MANA  and  Pythagoras  have  evenly  distributed 
terrain  effects  on  entities  motion.  These  models  are  highly 
scripted,  which  give  them  a  high  degree  of  usability  but 
limited  stochastic  application.  Their  rigid  and  complex 
development  gives  them  validation  in  real-world 
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applications,  such  as  training  and  mission  rehearsals; 
however,  scenario  generation  was  dependent  on  a  high  level 
of  proficiency. 

1 .  JCATS 

The  JCATS  simulation  results  were  used  from  a  previous 
study  conducted  by  Lieutenant  Richard  Jimenez,  U.S.  Navy. 
His  results  are  described  within  the  unpublished  article 
"Assessing  the  Requirements  for  the  transformable  Craft:  A 
Framework  for  Analyzing  Game  Changing  Capabilities." 
Jimenez's  (2010)  study  that  was  in  conjunction  with  the 
Systems  Engineering  studies  of  T-craft  research  at  NPS . 
This  work  was  designed  to  support  a  direct  evaluation  of 
JCATS  simulation  capabilities  of  an  SBE  using  the  Advanced 
Scenario  as  the  basic  framework.  Jimenez  was  also  able  to 
establish  a  concept  of  operations  scenario  for  data  farming 
and  conducting  large-scale,  multi-variable  analysis  on  SBE 
capabilities . 

JCATS  is  a  deterministic  computer-based  model  that 
offered  a  high  level  of  accuracy  to  SBE  Scenarios.  Its  high 
fidelity  of  entity  capabilities,  which  incorporates  actual 
physical  restraints,  enabled  simulations  results  to  emulate 
real-world  characteristics.  Military  applications  have  been 
for  training,  analysis,  and  mission  planning.  JCATS 
usability  comes  from  its  ability  to  simulate  urban  terrain 
to  support  both  asymmetrical  along  with  conventional  threat 
environments,  along  with  allowing  users  to  manipulate 
entities.  JCATS  has  a  wide  range  of  functionalities  with 
models  of  individual  soldiers,  vehicles,  and  weapons  systems 
(USJFCOM,  2010)  .  JCATS  was  designed  to  be  a  virtual 
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simulation  with  human-in-the-loop  decisions  being  made. 
However,  a  constructive  approach  was  taken. 

2.  MANA 

MANA  is  a  stochastic  AABM  that  attempts  to  bridge  the 
gap  in  deficiencies  in  highly  detailed  models  such  as  Janus 
Simulator  from  Training  and  Doctrine  Command  White  Sand 
Missile  Range,  Close  Action  Environment  model  from  the 
Defense  Science  and  Technology  Officer  (DSTO) ,  and  JCATS. 
The  use  of  AABM  is  centered  on  analysis  of  individual  unit 
actions  in  a  bottom-up  approach  to  warfare.  MANA  was 
developed  from  two  basic  concepts:  behavior  and  priority 
settings.  This  simulation  design  expanded  from  the  Marine 
Corps  Combat  Development  Commands'  Project  Albert  and  the 
Enhanced  Irreducible  Semi-Autonomous  Adaptive  Combat  (ISAAC) 
Neural  Simulation  Tool  (EINSTien) .  The  use  of  the  model  was 
derived  from  the  use  of  entity  attributes  that  govern 
actions  and  decision  making.  The  non-linear  nature  of  model 
outcomes  was  important  in  obtaining  a  stochastic  result 
(Lauren  &  Stephen,  2002)  . 

3 .  Pythagoras 

Similar  to  MANA,  Pythagoras  is  a  next  generation 
Project  Albert  concept  that  is  open-sourced  from  the  U.S. 
Marine  Corps.  Pythagoras  is  the  introduction  of  AABM  into 
simulation  by  Northrop  Grumman  to  use  Fuzzy  Logic  in  a 
Graphical  User  Interface  (GUI)  program.  The  basic  idea 
behind  Pythagoras  was  to  enable  analyzers  to  create 
behaviors  and  not  the  software.  It  has  the  capability  to 
use  probability  tables,  but  more  importantly  is 
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stochastically  based  on  single  entity  decision  making 
(Bitinas,  Henscheid,  &  Troung,  2003) . 

Time-step  based  models  can  provide  a  wide  range  of 
interactions  for  the  SBE  Scenario  analysis.  Models  like 
MANA  and  Pythagoras  incorporate  autonomous  agent-based 
models  and  inject  stochastic  processes  into  a  scripted 
model.  JCATS  supports  entity  based  physics  of  individual  T- 
craft  units  allowing  for  the  environmental  factors  to  be 
integrated  into  the  SBE  Scenarios .  MANA  and  Pythagoras 
provide  attribute  based  interfaces  that  enable  users  to 
influence  entities  actions  and  provide  randomness  to  the  SBE 
Scenarios . 

C.  NEXT-EVENT  BASED  MODELS 

A  next-event  or  Discrete  Event  Simulations  (DES)  are 
applied  to  many  computational  problems  that  occur  over  a 
finite  amount  of  time  (Gordon,  1978) .  The  typical  models 
are  single  server  and  queuing  event  scenarios.  The  M&S 
tools  evaluated  were  NPS  Simkit  DES,  Rockwell  Automation 
Arena  software  simulation,  and  Lockheed  Martin''  s  Naval 
Simulation  System  (NSS) ,  located  at  NPS.  The  T-craft 
scenario  was  applied  to  the  three  simulation  programs  and 
evaluated  for  desired  functionality  for  modeling  and 
simulating.  DES's  wide  range  of  applications  made  it 
suitable  for  measuring  performance  parameters.  DES  provided 
analysis  data  on  processes  involving  T-craft  and  its  ability 
for  cargo  and  equipment  transfer  to  and  from  the  SeaBase 
Operations . 
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1. 


Naval  Simulation  System 


NSS  is  an  object-oriented  Monte  Carlo  simulation 
developed  by  Space  and  Naval  Warfare  Systems  Command 
(SPAWAR)  .  It  is  a  DoD  M&S  tool  for  multi-warfare  mission 
area  analysis.  Previous  uses  have  been  operational 
planning,  systems  effectiveness,  and  fleet  exercises.  Its 
ability  to  receive  information  makes  it  useful  for  analyzing 
ongoing  operations  course  of  actions.  NSS  provides  measures 
of  effectiveness  and  performance  for  predetermined 
categories  that  enable  analysis  of  virtual  systems  (Metron 
Inc,  2007 ) . 

2 .  Simkit 

Simkit  is  a  simulation  package  used  for  creating  DES 
models  with  a  Java  based  computer  program  language.  Time- 
steps  within  Simkit  are  event  driven  rather  than  timed 
incremented.  Simkit  can  be  utilized  for  movement  and 
sensing  events  in  a  military  scenario  and  is  based  on  event 
graph  logic.  Entities  were  represented  in  an  abstract  way 
as  to  emulate  the  real  characteristic  of  systems.  Simkit  is 
a  component-based  modeling  tool  that  used  an  Application 
Programmer  Interface  (API).  This  is  fundamentally  different 
that  GUI  models  (Buss,  2002) . 

3 .  Arena 

Arena  is  a  Monte  Carlo  DES  similar  to  Simkit  but 
provides  a  GUI  vice  an  API.  This  difference  in  simulation 
design  allowed  for  animation  of  the  model  and  user  interface 
vice  direct  interface  with  program  code.  The  usability  of 
Arena  is  what  enables  decision  makers  to  easily  obtain 
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results  through  their  current  operating  system.  According 
to  the  Rockwell  Animation  Company,  the  use  of  Arena 
simulations  in  the  health  care  industry  has  shown  benefits 
in  patient,  staff,  and  facility  studies  to  improve  admission 
processes  and  planning  (RA,  2007) . 

Next-event  based  models  enhanced  processing  of  the  SBE 
Scenario  events  to  allow  for  precise  adjudication  of 
interactions.  NSS  was  similar  to  JCATS,  in  that  the  physic 
modeling  of  the  entities  provides  environmental  restraints, 
but  added  to  the  processing  power  of  the  SBE  Scenario  by 
precisely  accounting  for  interaction  or  engagement.  M&S 
tools  like  Simkit  and  Arena  provided  another  benefit  to  a 
SBE  Scenario,  which  was  modeling  the  interactions  vice  the 
entities.  The  flow  chart  analysis  enabled  the  user  to 
analyze  the  SBE  Scenario  to  affect  changes  and  improvement 
the  efficiency.  Simkit  added  another  adjudication  dimension 
by  being  able  to  adjudicate  limited  interaction  (user 
defined),  where  Arena  was  strictly  flow  chart  assessment. 
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IV.  CAPABILITIES  HIERARCHY 


A.  DEFINING  SEABASE  ENABLER  CAPABILITIES 

The  overarching  goal,  as  described  in  Chapter  I,  was  to 
define  the  needs  of  a  SBE  in  future  operations  and  translate 
them  into  capabilities  for  a  simulation  or  a  "suite  of 
simulations"  that  can  be  applied  broadly  across  the  M&S 
solution  space.  The  capability  hierarchy  is  defined  as  the 
body  of  functionalities  that  a  simulation  may  possess  to 
model  SBE  Scenarios.  An  example  of  functionality  is  the 
control  panels  used  in  the  windows  operating  system  for 
Personal  Computers  where  settings  of  the  display  (screen) 
can  be  directly  adjusted  with  instant  feedback  to  the  user. 
User  feedback  is  at  the  heart  of  M&S  and  why  it  is  extremely 
useful  for  analysis.  Modeling  a  system  seems  to  require 
unique  setting  properties  that  enable  the  translation  from 
real  world  to  a  synthetic  environment.  These  properties 
that  allow  for  modeling  are  what  will  be  described  as 
capabilities  for  a  simulation.  The  generation  of 
capabilities  discussed  in  Chapter  II  link  to  the  application 
of  these  capabilities  within  the  seven  M&S  domains  (DoD, 
2000)  . 

M&S  attempts  to  offer  insights  into  performance  of 
technology  in  artificial  environments.  The  development  of 
advanced  technology  has  started  to  rely  heavily  on  M&S  for 
testing  of  concepts.  M&S  partially  allows  for  a  translation 
of  simulation  results  to  performance  parameters  that 
advanced  systems  may  possess  in  real  settings.  The  specific 
needs  of  SBE  present  a  challenge  to  developers,  requiring 
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assumptions  to  be  made  on  future  environments  and 
capabilities.  Decision  makers  are,  in  turn,  forced  to 
consider  key  system  parameters  and  performance  levels 
without  the  benefit  of  having  a  proven  system  to  base 
judgment  on.  Simulations  available  to  those  groups  are  also 
available  to  academia,  including  research  work  conducted  by 
NPS .  Simulations  chosen  for  this  comparison  of  capabilities 
were  based  on  M&S  tools  available  at  NPS. 

The  T-craft  is  an  ideal  candidate  for  M&S  analysis. 
The  modeling  of  T-craft  as  an  SBE  involves  the  development 
of  scenarios  to  help  identify  potential  requirements  of  a 
simulation.  The  dynamics  of  the  SBE  situation  allowed  for 
the  extraction  of  simulation  functionalities  that  were 
essential  for  actually  modeling  an  SBE.  What  drives  that 
need  for  modeling  a  SBE?  The  T-craft  projected  capabilities 
are  not  typical  of  a  traditional  amphibious  craft.  SBEs  are 
being  designed  to  fill  the  gaps  of  current  landing  craft 
that  are  limited  in  cargo  capacity.  The  overarching  goal  of 
using  M&S  tools  for  analysis  of  T-craft  is  to  show  options 
in  SBO . 

B.  MEASURES  OF  EFFECTIVENESS 

The  objective  of  modeling  a  SBE,  such  as  T-craft,  was 
to  represent  Basic  and  Advanced  Scenarios,  allowing  for  the 
assessment  of  T-craft' s  responses  and  simulation 
capabilities.  Given  that  SBE  concepts  are  being  developed 
for  cargo  transfer,  the  Measures  of  Effectiveness  (MOE) 
could  then  be  directly  linked  with  the  outcomes  of  the  four 
situations  mentioned  in  the  previous  chapters.  MOEs  were 
only  briefly  introduced  to  relate  the  importance  of  cargo 

transfer  in  SBE  situations  to  the  simulation  capabilities. 
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A  possible  MOE  that  was  considered  with  humanitarian 
relief  efforts  is  the  approval  of  public  opinion  towards 
relief  efforts  that  are  received  by  host  nations.  Measures 
used  for  performance  were  the  delivery  of  cargo  and 
equipment  to  forces  in  combat  operations.  In  other  words, 
100  percent  of  cargo  and  equipment  delivery  should 
effectively  increase  public  opinion  or  sustain  combat 
operations  by  use  of  SBE  large  capacity  capabilities.  Thus, 
T-craft' s  cargo  capacities  offer  potential  support  to  a  wide 
range  of  military  operations. 

C.  MEASURES  OF  PERFORMANCE 

The  Measures  of  Performance  (MOP)  that  were  used  for 
the  Basic  and  Advanced  Scenarios  were  general  and  may  not  be 
available  in  all  M&S  tools.  These  MOPs  were  introduced  to 
evaluate  whether  an  analysis  capability  was  available  within 
a  simulation  program.  The  main  MOP  was  defined  as  the 
amount  of  cargo  transferred  to  the  line  of  embarkation.  In 
this  research,  the  line  of  embarkation  was  defined  as  the 
shore  landing  site  along  the  coastline.  Cargo  transfer  was 
defined  as  the  transfer  of  any  resource  carried  by  T-craft 
to  an  entity  in  the  model  that  represented  a  shore  landing 
site  similar  to  the  crisis  relief  area  of  operations.  The 
secondary  MOP  was  transit  times  associated  with  movement  of 
the  SBE  to  shore  landing  sites  from  debarkation  points.  The 
third  MOP  was  the  survivability  of  T-craft  in  a  hostile 
environment  with  varying  hostile  and  escort  forces. 
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1. 


Cargo  Transfer 


It  was  important  to  distinguish  the  differences  between 
cargo  and  eguipment  that  could  be  carried  by  naval  craft. 
In  this  research,  cargo  referred  to  supplies  other  than 
large  machinery  that  could  be  used  for  amphibious  assaults. 
T-craft  is  projected  to  have  a  cargo-carrying  capacity  that 
is  unprecedented  by  previous  landing  craft  used  for  cargo 
transport.  According  to  Jane's  Fighting  Ships,  current 
capabilities  in  cargo  transfer  craft  are  nominally  at  60  ton 
payload.  The  capability  of  T-craft  storage  capacity  is 
projected  to  be  approximately  10  times  that  of  those  craft 
in  use  today.  Cargo  capabilities  are  difficult  to  represent 
in  real-world  systems  and  in  simulations  where  modeling  the 
dynamics  of  transferring  quantities  is  not  standardized. 

Representing  cargo  in  M&S  tools  was  limited,  and  use  of 
unrelated  simulation  objects  were  used  to  act  similar  to  a 
type  of  resource.  In  the  two  types  of  simulations,  time- 
step  and  next-event,  there  were  different  methods  of 
modeling  cargo  and  transfers  of  quantities  from  one  entity 
to  another.  Given  the  diversity  of  the  simulations,  there 
was  no  standard  way  to  represent  cargo  or  a  transfer  of  that 
cargo.  Common  elements  present  across  simulations  were  fuel 
elements  that  were  used  in  time-step  simulations. 

2 .  Transit  Times 

Logistics  support  is  highly  dependent  upon  what  time 
the  supplies  arrive  to  the  front  lines.  Sequencing 
operations  are  often  limited  to  logistic  capabilities.  An 
important  aspect  of  modeling  a  SBE  was  the  time  required  for 
a  T-craft  to  transit  from  debarkation  point  to  the  SBO  and 
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then  to  the  shore.  Transit  times  are  helpful  in  determining 
needed  speeds  of  a  T-craft  in  different  modes.  These  needs 
are  derived  from  mission  requirements  and  end  users  needs. 
Transit  times  were  used  to  confirm  the  presents  of  a 
capability  within  a  simulation,  and  its  ability  to  measure 
time  distance  problems  that  could  be  integral  to  decision 
making  and  planning. 

3 .  Survivability  Rates 

The  third  MOP,  survivability  of  a  SBE,  was  the  constant 
element  in  simulation  development.  T-craft  prototypes  are 
being  developed  with  limited  self  defense  and  will  require 
protection  in  a  hostile  environment.  The  Advanced  Scenario 
introduced  a  hostile  environment  through  which  the  T-craft 
transited.  Survivability  was  defined  as  T-craft  being  able 
to  transfer  cargo  to  the  shore  landing  site,  while 
maintaining  a  capable  speed  of  40+  knots  through  the  hostile 
environment.  The  use  of  this  MOP  on  simulation  capabilities 
was  that  damage  sustained  by  T-craft  in  iterations  should 
have  an  effect  on  performance. 

D.  M&S  IMPACT  ON  SEABASE  ENABLER  SITUATIONS 

The  introduction  of  a  potential  revolutionary  platform 
like  T-craft  may  have  dramatic  effects  on  current  force 
structures  and  deployment  considerations.  Stakeholders  like 
the  Navy,  Marine  Corps,  Army  and  other  key  military  entities 
have  collaborated  with  ONR  to  develop  the  SBE  capabilities 
required  for  operations  in  SBO  (Flitter  &  Sintic,  2009)  . 
These  capabilities  were  published  in  the  BAA  05-020  by  the 
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ONR.  In  general,  M&S  is  well  suited  to  model  INPs  like  T- 
craft  and  give  decision  makers  key  insights  to  its  potential 
as  a  SBE . 

Although  the  two  types  of  simulations  contributed  to 
the  goal  of  analyzing  a  SBE  in  the  situations  like  Peace 
Keeping  and  Major  Theater  War,  their  advantages  vary.  AABM, 
which  is  commonly  found  in  time-step  based  models,  provided 
a  dynamic  environment  to  model  interaction  with  other  forces 
in  a  given  scenario.  This  allowed  for  adjudication  of 
engagements  with  force-on-force.  Time-step  based  modeling 
also  enabled  replications  and  the  integration  of  complex 
algorithms  to  perform  data  analyses.  A  DES  modeled  specific 
processes  within  a  scenario  to  isolate  factors  and  measure 
parameters  that  may  be  critical  for  decision  makers. 

The  disadvantages  were  centered  on  the  purpose  and  use 
of  each  type  of  simulation.  Defining  capabilities  of  a 
simulation  for  a  SBE  required  analysis  of  a  wide  range  of 
simulation  functionalities  that  were  partially  incorporated 
into  these  two  types  of  M&S  tools.  DES  were  not  as 
versatile  as  agent-based  models.  DES  are  queuing  models 
that  have  stochastic  inputs  with  distributed  results. 
Agent-based  models  were  usable  and  scalable  but  rigid  in 
applications  of  performance  measures.  Most  simulations  did 
not  allow  access  to  programming  code,  which  was  critical  to 
modeling  a  SBE  for  accurate  representation  in  simulation 
environments.  AABM  was  highly  usable  and  offered  the  fewest 
disadvantages.  AABM  had  complex  requirements  for  measuring 
performances  and  obtaining  tangible  results. 

The  downside  to  M&S  was  that  a  single  simulation  could 
not  be  used  to  answer  every  question  of  the  SBE  Scenario. 
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Investigating  the  four  MOP  required  multiple  points  of  view 
into  the  SBE  concept.  These  types  of  simulation  offered 
different  perspectives  on  all  MOPs  that  were  analyzed  in  T- 
craft  scenarios.  For  example,  an  AABM  determined  the 
effective  number  of  escort  ships  needed  in  an  Advanced 
Scenario  for  the  safe  transit  of  the  SBE  with  limited 
defenses.  AABM  could  not  be  used  to  assess  the  cargo  load 
capacity  and  transfer  rates  that  a  DES  could  model  with  more 
accuracy,  with  regards  to  waiting  queues  processes.  DES  was 
also  well  suited  for  measuring  multiple  iterations  in  tandem 
or  in  series.  Nevertheless,  the  survivability  of  T-craft 
with  escort  ships  may  have  been  best  analyzed  in  a  time-step 
simulation  with  look  up  tables  for  real-world  probability 
engagements . 

Basic  surface  engagements  and  cargo  transfers  were  used 
for  modeling  T-craft  projected  capabilities.  The  Basic  and 
Advanced  Scenarios  described  in  Chapter  V  were  used  for  the 
purpose  of  defining  a  set  of  capabilities  that  all  models 
possessed.  The  following  sections  delineate  the  capability 
hierarchy  used  for  analysis  of  the  six  M&S  tools. 

E .  CAPABILITY  HIERARCHY 

M&S  tools  have  inherent  functionalities  that  can  be 
used  in  all  areas  of  DoD  and  industry  for  analysis,  testing, 
training,  and  planning.  These  functionalities  were  the 
backbone  of  the  capability  hierarchy.  Figure  5  illustrates 
the  tiers  of  the  capability  hierarchy.  The  four  levels  of 
the  capability  hierarchy  are:  Capability  of  a  simulation. 
Characteristics  of  a  Capability,  Abilities  of  a 
characteristic,  which  were  referred  to  as  "ilities,"  and 
Traits  of 


"ilities . 


The  Trait  tier  represented 
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functionality  groupings  that  were  used  to  evaluate  M&S 
tools.  This  section  delineates  the  hierarchical  structure 
and  body  used  for  analysis  of  the  six  M&S  tools  used  in  this 
study.  The  levels  of  description  directly  reference  M&S 
domain  ideology  and  use  of  common  applications  in  DoD  to 
support  the  preferred  capabilities  of  an  M&S  tool. 

The  capabilities  in  the  hierarchy  were  derived  from  M&S 
Domains  in  DoD,  and  are  Usable,  Flexible,  and  Scalable  (DoD, 
1995)  .  Each  simulation  was  evaluated  based  on  how  well  it 
fit  into  the  hierarchy  of  capabilities  using  the  Basic  and 
Advanced  Scenarios . 


Figure  5 . 


Capability  Hierarchy  Structure. 


1 .  Evaluation 

The  evaluation  of  M&S  tools  were  based  on  a  Boolean 
value  in  an  attempt  to  removed  subjectivism  from  the  base  of 
the  hierarchy.  The  functionalities  were  observed  and 
recorded  as  being  present  or  not.  This  enabled  the 
application  of  values  to  be  applied  to  functionalities. 
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Value  of  one  was  assigned  to  an  observe  functionality,  where 
the  total  number  of  observed  functionalities  were  used  as 
proportions.  The  use  of  probability  properties  were  used 
for  evaluation.  This  research  kept  the  values  the  same  for 
all  functionalities  but  recognize  that  a  weighted  scale  be 
applied  to  future  evaluations  where  elements  of  the 
hierarchy  could  be  more  important  than  others . 

2.  Roll-Up  method 

The  functionalities  within  the  capability  hierarchy 
were  used  as  the  baseline  total  proportionality  for 
evaluation.  This  section  explains  the  method  used  to  roll 
up  the  total  probability  of  the  individual  capability.  A 
single  functionality  was  set  equal  to  a  value  of  one.  The 
total  number  of  functionalities  within  a  given  capability 
was  then  used  to  determine  the  contribution  of  each  one, 
where  the  variable  (f)  represents  functionality.  The 
summation  of  each  capability  was  then  combined  up  the 
hierarchy  to  the  characteristic  level  and  follows  the 
Probability  Assignment  Rule  (De  Veaux,  Velleman,  &  Bock, 
2009,  p.  371) . 

n 

^  -^I+  ■*v+l+  f;+2+  +  +  Equation  (1) 

t  -  1 

A  roll-up  method  was  then  used  to  calculate  the 
contribution  of  hierarchy  elements  in  the  capabilities. 
Using  Equation  (1),  the  total  contribution  of 
functionalities  of  a  trait  were  summed  and  rolled  up  into 
the  hierarchy  to  determine  the  capability  of  an  M&S  tool. 
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This  was  done  by  normalizing  the  capabilities  vector.  The 
variable  (c)  represents  the  three  capabilities  defined  in 
the  hierarchy. 


C  = 


cL  =  Usability 
c2  =  Flexibility 
c3  =  Scalability 


Equation  (2) 


The  roll-up  method  was  used  to  compare  the  three 
capabilities  of  an  M&S  tool.  The  asymmetrical  design  of  the 
capabilities  hierarchy  was  not  conducive  for  a  one  on  one 
comparison  of  single  elements.  The  number  of 
functionalities  in  each  capability  was  not  standardized 
across  the  hierarchy,  therefore,  a  standardization  method 
needed  to  be  used.  Normalizing  the  probability  values  were 
calculated  similar  to  normalization  of  vectors  where  the 
varying  number  of  functionalities  are  accounted  for.  Once 
the  capabilities  were  standardized,  the  average  was  then 
calculated  to  compare  the  capabilities  of  all  the  M&S  tools 
to  determine  the  best  solution  for  a  simulation  or  "suite  of 
simulations . " 

F.  USABILITY 

The  definition  of  usability  as  defined  in  American 
Heritage  is  the  capability  of  any  given  object  to  be  used. 
The  ability  of  a  simulation  to  be  used  by  users  certainly 
was  a  capability  that  was  required  when  applying  it  to 
analysis.  The  meaning  of  usability  was  also  open  to 
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interpretation  of  the  users.  There  are  many  aspects  of  M&S 
that  could  be  measured  and  observed  to  determine  if  a 
simulation  is  (1)  available  and  (2)  usable  by  decision 
makers  (who  are  not  computer  programmers) .  Figure  6  shows 
the  hierarchical  structure  for  Usability. 


Figure  6.  Usability  Hierarchy  Branches. 


The  end  user' s  level  of  knowledge  of  simulations  was 
ultimately  dominated  in  how  usable  it  was,  but  there  are 
other  factors  that  allow  for  a  simulation  to  be  useful  in 
DoD.  One  important  aspect  of  a  simulation  must  be  that  it 
has  been  W&A.  This  concept  of  W&A  was  considered  as  a  key 
characteristic  to  usable  simulation  due  to  its  rigorous 
testing  and  application  of  a  simulation's  capabilities  (DoD, 
2003)  . 

The  second  characteristic,  user  interface,  applied  to 
features  that  the  user  accesses  for  manipulation  of  settings 
in  the  M&S  tool  and  those  functionalities  to  create  models. 
DoD  applications  of  M&S  tools  often  require  explicit 
interface  methods  to  handle  a  wide  range  of  settings  for 
modeling  scenarios. 
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1. 


Validation 


The  validation  of  M&S  tools  was  important  because  of 
the  continued  support  of  major  DoD  decision  making 
organizations  and  processes.  Validation  was  defined  as  the 
process  of  determining  the  degree  to  which  the  simulation 
could  accurately  represent  the  real  world  (DoD,  1998) .  This 
was  a  key  element  with  regards  to  usability  of  a  simulation. 
The  W&A  process  was  not  directly  used  for  determining  the 
simulation  capabilities,  but  had  a  role  in  defining  those 
end  user  needs  (DoD,  2003)  . 

a.  Construct  Abilities 

Given  that  a  simulation  was  validated  for  use,  the 
first  step  in  assessing  its  usability  was  to  assess  its 
ability  to  handle  complex  SBE  Scenarios.  This  included  the 
ability  to  simulate  multiple  entities  in  an  environment  that 
presented  interactions  among  multiple  entities.  An  entity 
was  a  single  player  or  agent  in  a  simulation  that  was 
defined  by  the  user  of  the  M&S  tool  (Bonabeau,  2002)  . 
Figure  7  shows  the  hierarchical  structure  for  "construct 
abilities . " 
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Figure  7  . 


"Construct  Abilities"  Hierarchy  Branches. 


(1)  Dynamic  Situation.  The  first  situation 
to  consider  was  the  dynamics  of  possible  scenarios  with 
multiple  entities  that  acted  as  individuals  interacting  in  a 
simulation  environment.  In  this  thesis,  a  dynamic  situation 
was  defined  as  a  non-deterministic  model  where  entities 
acted  independently  from  one  another  and  whose  actions  were 
not  predetermined.  AABM  are  an  example  in  which  the 
simulations  could  create  a  dynamic  situation  with  multiple 
personal  attribute  settings.  Other  aspects  of  dynamic 
situations  were  associated  with  the  individual  entities  and 
their  place  within  the  simulation  environment.  There  are 
several  functionalities  that  were  present  in  a  dynamic 
situation  that  begin  with  probabilities  to  facilitate  a  non- 
deterministic  model.  Other  functionalities  included 
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individual  entities  properties  and  interactions  of  those 
individual  entities  with  each  other,  which  did  or  did  not 
include  probabilities. 

The  idea  of  using  probabilities  is  not  new  to 
military  operations  and  planning.  Classic  war  gaming 
methods  have  used  probability  tables  to  simulate  the 
partially  random  results  of  interactions  of  units  on  the 
battlefield.  One  way  to  make  a  model  non-deterministic  is 
to  use  sensor  and  weapon  probability  tables.  The  level  at 
which  they  were  implemented  was  based  on  the  resolution 
needed,  but  in  this  thesis  basic  use  of  probabilities  was 
sufficient  to  display  the  functionality  in  the  simulation. 

Inherent  in  dynamic  situations  is  the 
individual  entities  characteristics  that  are  displayed. 
AABM  represented  this  functionality  with  a  high  degree  of 
effectiveness.  The  level  of  resolution  at  the  individual 
entity  provided  the  maximum  amount  of  dynamics  in  the 
simulation.  The  first  functionality  was  that  the  individual 
unit  actions  were  different  from  all  other  elements  within 
single  simulation  iterations.  It  then  followed  that  if  high 
resolution  was  present,  individual  entities  also  needed  to 
possess  basic  viewable  characteristics  like  entity  course, 
speed,  positional  data,  refueling  rates,  and  cargo 
capacities  levels. 

An  important  functionality  in  dynamic 
situation  was  the  access  to  individual  entity  controls. 
AABM  are  rooted  in  the  concept  of  controllable  attributes 
for  agents  within  the  simulation.  These  personal  settings 
included  but  were  not  limited  to  preferences  to  other 
entities,  task  oriented  actions,  and  objective  completion. 
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A  simulation  that  enabled  the  user  to  adjust  personal 
settings  of  an  entity  possessed  this  functionality. 

The  use  of  Semi-Automated  Forces  (SAF)  has 
become  obsolete  in  the  development  of  AABM.  The  reason  for 
listing  these  types  of  forces  was  to  include  a  wide  range  of 
aspects  in  the  hierarchy  to  be  able  to  apply  it  over 
simulations  in  M&S.  SAF  were  the  first  attempt  to  represent 
human  behavior  in  a  constructive  simulation.  There  may  be 
some  level  of  automation  to  entities  in  M&S  that  is  not 
associated  with  AABM.  SAF  covered  all  other  force 
automations  that  were  encountered  through  this  research 
(DoD,  1995) . 

Communications  added  complexity  to  dynamic 
situations  by  allowing  information  of  scenario  events  to  be 
distributed  to  multiple  entities.  The  use  of  communications 
by  entities  provided  a  situational  awareness  influencing 
actions.  Operations  that  relied  on  communications  were 
defined  as:  Command  and  Control,  Military  operations  other 
than  Warfare,  and  Logistical. 

Waiting  Queues  are  typically  characterized  in 
logistical  operations  where  transfers  occur  and  are  time 
dependent.  A  DES  is  designed  to  specifically  create  waiting 
queues  to  measure  transfer  rates  and  amounts.  This  property 
was  the  basis  for  introducing  waiting  queue  functionality  in 
the  hierarchy.  A  simulation  with  the  capability  to  delaying 
transfers  based  on  facilitation  restriction  of  entities 
capabilities  was  defined  to  have  waiting  queue 
functionality. 
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Replicable . 


(2)  Replicable.  The  ability  to  run  a 
simulation  over  multiple  iterations  is  to  allow  for  varying 
results  in  a  dynamic  situation.  The  main  reason  for 
simulations  to  be  replicable  was  to  provide  statistical 
data.  The  M&S  tools  provided  a  range  of  possible  answers 
for  users.  The  data  collected  from  the  replication  provided 
insights  to  model  performance.  This  information  would 
otherwise  not  be  obtained  without  the  expensive  generation 
of  actual  prototypes  in  the  physical  development  of  the 
system . 


M&S  tools  should  have  certain  control 
functionalities  associated  with  the  replication  of  models. 
The  users  should  have  the  ability  to  define  and  use  a  model 
in  the  simulation.  This  classically  is  seen  in  time-step 
simulations  where  entity  models  are  available  for  use  in  the 
simulation  without  access  to  action  settings.  This  has  been 
recently  addressed  in  AABM  where  the  default  settings  are 
not  sufficient  for  simulation  and  attention  must  be  paid  to 
the  design  of  the  simulation.  The  second  functionality  was 
the  ability  for  the  user  to  define  a  predetermined  number  of 
replications  for  a  simulation.  When  dealing  with  complex 
models,  time  played  a  considerable  factor  in  computational 
run  time. 


Along  with  replication,  control  is  the 
ability  to  select  specific  MOP.  A  user  should  be  able  to 
select  pertinent  MOP  for  the  simulation.  This  functionality 
also  assisted  in  reducing  time  in  other  ways.  Simulation 
output  often  was  not  designed  effectively  to  allow  users  to 
rapidly  depict  analysis  information  at  any  point  in  the 
iteration.  A  spot  sampling  of  information  in  the  run  should 
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be  functionality  to  allow  the  user  to  select  key  MOP  for 
output  files  increased  the  analysis  capability.  MOP 
included  system  parameters  associated  with  times  or  user 
defined  variables. 

A  simple  functionality  was  for  users  to  have 
the  ability  to  reset  simulation  parameters  during  the 
simulation.  This  included  the  need  to  start  and  stop  the 
simulation  base  on  certain  criteria.  User  needs  vary  with 
situational  requirements  and  M&S  tools  must  be  versatile  in 
handling  both  depth  and  breadth  of  requirements. 

The  last  functionality  of  replication  that 
was  used  in  this  research  was  accuracy.  Accuracy  was 
defined  as  the  ability  of  a  simulation  to  produce  a  result, 
and/or  contained  in  a  confidence  interval  common  to 
statistical  analysis.  Optimization  methods  often  had 
difficulty  in  determining  solutions  to  complex  situations 
with  multiple  variables.  This  often  left  simulations 
without  ends.  It  was  foreseeable  that  optimization 
approaches  will  be  employed  in  M&S  analysis  of  DoD  systems, 
therefore  accuracy  was  included  in  the  capabilities 
hierarchy . 


Jb.  Supportabilities 

The  second  step  in  assessing  M&S  tools  usability 
was  the  level  of  supportability  that  simulations  had  in  the 
form  of  user  execution.  W&A  required  simulations  to  have 
minimum  levels  of  information  (support  and  documentation) 
associated  with  M&S  tools  to  be  approved  for  DoD  use  (DoD, 
2003) .  These  support  issues  may  be  key  to  use  of 
simulations  in  DoD  at  the  higher  levels  of  the  decision 
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making  process.  W&A  requirements  for  accreditation  were 
the  basis  for  support  "-ilities"  of  a  simulation  in  the 
hierarchy.  The  information  listed  in  the  W&A  instruction 
is  the  standard  for  M&S  tools  used  and  are  common  in  high 
profile  models.  The  two  categories  of  supportabilities  are 
contractor  support  and  user  documentation.  Figure  8  shows 
the  hierarchical  structure  for  Supportabilities. 
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Figure  8  . 


Supportabilities  Hierarchy  Branches. 


(1)  Contractor  Support.  There  are  basic 
elements  of  simulation  information  that  should  be  contained 
in  the  associated  files  of  a  program  that  the  contractor  or 
programmers  provide.  A  comparison  between  the  defined 
capabilities  hierarchy  and  the  W&A  process  are  listed  in 
Table  4.  This  comparison  was  used  to  show  the  validity  of 
informational  items  that  were  used  in  the  capability 
hierarchy,  which  indicated  what  additional  items  were  used 
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in  evaluations  with  All  items  listed  in  the  supportabilities 
category  are  delineated  in  the  capabilities  hierarchy. 

Supportabilities  Comparison 

Verification  Support  ilities 

Verification  Agents 

Version/Release  Simulation  Version  Number/Release 

information 

Identify  Developing  Organization  Listing  authority  sources  used  to 

produce  simulation  code 

Methodologies 
Verification  Results 

Validation  Support  ilities 

Validation  Agents 
Federation  Version 

Identify  Developing  Organization  Listing  authority  sources  used  to 

produce  simulation  code 

Simulation  Conceptual  Model 
Methodologies 
Validation  Data 
Validation  Results 
Limitations 

Sponsors  information  Listing  of  Points  of  Contacts  held 

with  the  M&S  tool 

Model  Intended  Use 
Requirement  Gaps 


Assumptions 


Scenarios 


Representation  of  concepts. 
Processes 

Environmental,  Missions, 
Organization,  &  Systems 
Representations 

Doctrine  Tactics,  Behaviors,  and 
Performance  Algorithms 

Capabilities  and  Limitations 
Evaluation 


W&A  Documentation 


Support  ilities 

Last  Upgraded  Information  of  program 
code 

Reach-back  Availability  -  User 
Capability  to  correspond  with 
contractors  on  simulation  issues 

Internet  Availability  -  Access  to 
documentation  and  information  items 
through  the  internet 

Training  Availability  -  Contractor 
supported  training  session  provided 
to  DoD  agencies  for  employees 
professional  development 

Feedback  Loop  -  System  in  place  to 
provide  lessons  learned,  answers  to 
current  questions,  and  update  center 
for  users 


■ 

I 


Table  4  . 


Supportabilities  Comparison  Against  W&A. 


Basic  informational  items  are  self 
explanatory  and  contain  the  simulation  specifications.  The 
more  complex  items  like  contractor  support  items  were 
expanded  in  this  section.  The  first  was  a  reach  back 
availability  that  pertains  to  the  continued  support  of  M&S 
in  DoD  throughout  the  life  cycle  process.  The  availability 
that  was  described  in  the  hierarchy  referred  to  contractors' 
use  of  simulations  in  parallel  with  DoD  components  for 
experimentation.  The  reach-back  support  line  item  was 
created  for  M&S  application  in  military  operations  that 
required  expertise  of  development  experts  for  analysis  of 
real-world  scenarios.  Simulations  used  in  DoD  to  solve  non¬ 
trivial  processes  may  be  relatively  simple  to  contractor 
development  entities. 

Exchange  of  program  user  information  was 
common  with  use  of  the  internet.  Web  site  availability  of 
M&S  tools  was  included  in  Supportabilities .  Simulations 
that  were  widely  used  in  the  DoD  provided  web  site  services 
to  users  for  capabilities  listed  in  Table  4.  Copyrights  and 
proprietary  rights  should  not  be  a  blocking  factor  for 
contractors  in  providing  information  to  users  that  have 
access  to  simulations  but  not  source  code  access.  Web  site 
availability  was  defined  in  this  hierarchy  as  internet 
availability  that  provided  an  outlet  to  find  operational 
information  on  simulations.  Along  with  internet 
availability,  there  should  be  a  feedback  loop  or  method  to 
give  users  the  positive  indications  of  progress  assistance 
with  challenges.  This  was  in  the  form  of  observable 
simulation  results  or  actual  correspondence  with 
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was  to  enable 


contractors.  The  goal  of  these  "ilities 
users  to  understand  and  correct  issues  with  operating  M&S 
tools . 

Purchase  of  M&S  systems  often  is  accompanied 
with  training  for  employees  but  training  is  not  necessarily 
up  to  standards.  Contractor  provided  training  of  M&S  tools 
was  invaluable  to  operating  and  analyzing  military 
situations.  DoD  maximizes  its  investment  in  M&S  with 
knowledgeable  operators  using  simulations  and  systems  to 
their  full  capacity.  Ultimately,  these  support  abilities 
contributed  to  the  usability  of  a  simulation.  There  were  no 
measures  to  determine  the  level  of  support  a  contractor 
provided  to  the  implementation  of  M&S;  supportabilities  were 
considered  to  possess  the  "ilities"  if  a  single  aspect  were 
present . 

(2)  Documentation.  Use  of  M&S  in  DoD  often 
relied  heavily  on  how  simulations  were  supported  for 
independent  modelers  and  decision-markers.  Documentation 
for  open  source  M&S  was  critical.  There  were  essential 
forms  of  documentation  that  made  the  M&S  tools  considerably 
easier  for  use  when  included  in  simulation  packages.  The 
most  common  form  of  documentation  was  the  user  manual 
associated  with  the  simulation.  Documentation  was  defined 
in  the  capabilities  hierarchy  as  any  simulation  that 


contained  a 

link 

to  the  user  manual 

within  the 

running 

program . 

User 

manuals  provided 

a  complete 

set  of 

information 

for 

operations  of  the 

simulation . 

Other 

publications,  similar  to  the  user  manual,  aided  the  user  in 
M&S  applications  and  uses  and  provided  additional 
information . 
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Functionality  tutorials  were  those 
informational  programs  within  the  simulation  to  facilitate 
the  creation  of  models  with  developer' s  instruction  and 
methods  for  proper  set-up.  This  was  defined  as  an 
instructional  function  in  the  simulation  that  assisted  the 
user  in  step-by-step  procedures  to  create  a  basic  model  that 
can  then  by  personalized  by  the  user  for  their  specific 
requirements.  Associated  with  tutorials  was  the  use  of  help 
windows  and  pop-up  information  that  rapidly  provided 
assistance  to  users. 

The  last  element  of  documentation  that  was 
defined  in  the  capabilities  hierarchy  was  on-line  support 
provided  by  contractors.  These  elements  were  considered  a 
part  of  documentation  because  the  information  provided  by 
the  above  elements  was  derived  from  the  developers  of  the 
simulation.  Online  support  from  contracting  companies,  and 
specifically  the  developers,  was  consistent  with  referring 
to  user  manuals.  This  is  another  form  of  documentation  that 
involved  correspondence  with  live  people  vice  documented 
information . 

2 .  User  Interface 

M&S  user  interfaces  must  handle  the  needs  of  non¬ 
computer  programmer  users  in  DoD  applications.  The 
invention  of  the  GUI  has  provided  the  capability  for  all 
users  to  interact  with  computer  software.  GUIs  were  an 
important  functionality  and  considered  vital  to  M&S 
applications.  Along  with  GUI,  there  were  "comprehensive 
ability"  parameters  that  are  DoD  requirements  for  operating 
M&S  tools.  Operation  of  M&S  tools  meant  that  users  be  able 

to  understand  and  work  with  symbols,  programming  language, 
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and  results  across  difference  branches  and  components  of 
U.S.  Armed  Forces.  Figure  9  shows  the  hierarchical 
structure  for  User  Interfaces. 


Figure  9.  User  Interface  Hierarchy  Branches. 

a.  Represent  Abilities 

Represent  abilities  were  the  key  for  users  to 
interface  with  simulations.  It  was  divided  into  two  traits; 
presence  of  GUIs,  and  "comprehensive  abilities".  The  common 
GUIs  in  software  are  interactive  windows  with  options 
available  for  users  to  select.  Comprehensive  able  traits 
referred  to  the  use  of  common  terms  and  knowledge  within 
simulations:  Can  a  simulation  be  used  by  different  users 

and  obtain  similar  results?  Representation  is  important  to 
decision  makers  and  modelers  that  attempt  to  use  M&S  tools 
in  vastly  different  ways  than  initial  design.  The  "ilities" 
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were  critical  to  modeling  advanced  concepts  that  were  not 
well  defined  for  previous  models  like  a  SBE . 

b.  Represent  Abilities  (GUI) 

There  are  common  GUIs  associated  with  the 
commercial  operating  systems.  M&S  users  are  familiar  with 
common  GUIs  and  can  quickly  adapt  to  a  simulation  with  GUIs. 
The  functionalities  listed  in  the  capability  hierarchy  were 
not  a  complete  listing  of  GUIs.  There  was  an  understanding 
that  there  was  no  limit  on  interface  options,  however,  this 
selection  of  items  was  presented  to  allow  for  a  comparison 
of  M&S  tools  in  this  research.  There  were  two 
functionalities  that  were  examined  that  made  comparisons  of 
simulations,  input  GUIs  and  set  up  wizards  that  were  similar 
to  tutorials. 

User  input  windows  were  found  in  virtually  every 
software  program.  Input  GUIs  were  defined  to  have  four 
basic  functions:  pull-down  menus,  check  boxes,  typed  in 
values,  and  adjustment  varying  sliders.  Other  GUIs  that  did 
not  fit  into  these  functions  were  recorded  in  the  analysis 
of  each  simulation. 

The  second  function  that  was  defined  in  the 
capabilities  hierarchy  was  the  presence  of  set-up  wizards. 
A  wizard  was  defined  as  the  integrated  instructional  GUI 
that  enabled  users  to  create  a  model  with  the  assistance  of 
the  simulation.  This  was  included  in  a  step-by-step 
instructions  created  by  developers  to  build  a  skeleton 
model.  The  wizard  assisted  in  modeling  a  specific  process. 
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c.  Represent  Abilities  (Comprehensive  Able) 

"Comprehensive  abilities"  refers  to  the  common 
application  of  simulation  and  their  results  across 
components  of  the  DoD.  There  were  two  parts  to 
"comprehensive  abilities";  information  availability  and 
transferability.  The  amount  and  type  of  information  that 
was  displayed  by  a  simulation  was  important  to  the  user' s 
understanding  of  model  processes.  Presenting  accurate 
information  was  a  capability  that  was  considered  in  this 
hierarchy.  The  method  in  displaying  information  was 
measured  in  this  analysis.  There  are  three  functionalities 
that  were  considered:  the  presences  of  (1)  help  menus,  (2) 
pop-up  information,  and  (3)  user  feedback  information.  User 
feedback  information  included  messages  that  give  status  or 
completion  indications. 

Transferability  was  defined  similarly  to  the 
ability  of  simulation  models  used  and  interpreted  by  outside 
entities  across  a  variety  of  users  and  user  backgrounds. 
There  were  three  functionalities  that  enable  this  ability: 
Common  terminology.  Standard  Symbology,  and  Object 
templates.  Simulations  are  under  implementation 
restrictions  dictated  by  DoD  as  set  forth  in  Joint  Pub  1-02. 
The  set  of  general  terms  common  to  DoD  were  used  and  apply 
to  M&S  tools  (DoD,  2001)  .  The  use  of  symbology  was  not  as 
common  in  DoD,  each  service  has  adopted  its  own  standard 
symbols.  Simulations  were  measured  by  the  use  of  any 
standard  set  of  symbology  employed  by  the  services.  The 
last  functionality  in  this  trait  was  the  object  templates 
that  referred  to  entities  used  in  protocols  like  Distributed 
Interactive  Simulation  (DIS)  and  High  Level  Architecture 


58 


(HLA) .  Simulations  were  analyzed  for  the  functionality  that 
they  could  send  information  to  other  simulations  based  on 
the  above  protocol  standards.  Networking  involves  protocols 
with  common  entities  that  are  predefined  in  Institute  for 
Electronic  and  Electrical  Engineers  standards.  DoD 
instituted  the  use  of  HLA  in  all  simulations  by  the  Under 
Secretary  of  Defense  (Acquisition  and  Technology)  in  1996. 
Object  templates  were  incorporated  into  comprehensive  able 
to  illustrate  simulations  were  integrated  in  multiple  ways 
other  than  internet  considerations. 

G.  FLEXIBILITY 

Flexibility  was  defined  as  the  ability  of  all  levels  of 
M&S  users  to  use  M&S  tools  for  analysis.  Flexible 
simulations  were  able  to  model  different  military 
applications  and  allow  users  to  set  model  parameters  to  test 
a  wide  variety  of  outcomes  in  a  timely  manner.  The  first 
characteristic  of  a  flexible  simulation  was  the  ability  for 
it  to  handle  a  spectrum  of  functionalities  that  could 
represent  real-world  systems.  Unfortunately,  the  level  of 
flexibility  was  difficult  to  measure  and  had  considerable 
variation.  The  amount  of  "model  ability"  needed  was 
determined  by  elements  of  the  specific  model.  BAA  05-020 
listed  T-craft  capability  requirements,  and  was  used  as  MOPs 
for  "model  ability"  (ONR,  2005)  .  Figure  10  shows  the 
hierarchical  structure  for  Flexibility. 
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Figure  10.  Flexibility  Hierarchy  Branches. 

The  second  characteristic  of  flexibility  was  stochastic 
processes  in  simulations  that  apply  randomness  to  provide  a 
sense  of  realism  in  outcomes.  This  randomness  introduced 
the  idea  of  chance  and  uncertainty  into  the  planning  phase. 
The  T-craft  concept  was  untested  and  required  the  full 
degree  of  uncertainty  and  randomness  into  its  required 
capabilities.  Simulation  capabilities  did  not  serve  the 
interest  of  developing  T-craft  as  a  viable  asset  without  the 
use  of  stochastic  processes  in  simulations.  Both  of  these 
characteristics  contributed  to  effective  use  of  M&S  tools 
and  enabled  users  to  rapidly  produce  results. 

1 .  Model  Able 

There  are  five  "ilities"  used  to  define  "model  ability" 
in  the  capability  hierarchy  that  extend  over  a  limited 
spectrum  of  functionalities  used  in  M&S  tools.  This  section 
is  used  to  analyze  the  simulations'  effectiveness  in 

representing  a  system  in  M&S.  These  "ilities"  ranged  from 
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environmental  effects  to  system  parameters  that  included  the 
ability  to  process  classified  material,  input  environmental 
databases,  and  scenario  object  representations. 
Adjustability  contributed  to  being  able  to  model  a  SBE  and 
involved  the  basic  system  attributes.  Other  "ilities" 
referred  to  how  the  model  was  handling  within  simulations, 
resolutions  of  forces,  and  scenario  environment.  "Model 
ability"  enabled  simulations  to  render  a  real-world  system 
in  a  constructive  simulation  environment. 

a.  Securities 

Securities  were  defined  as  the  safeguards  of  a 
simulation  to  handle  information  that  may  be  present  in  DoD 
modeling.  The  advantage  of  using  M&S  was  that  it  can 
provide  insight  to  scenarios.  These  scenarios  often 
contained  secure  information  that  may  be  sensitive  in  nature 
and  require  certain  considerations.  The  single  trait  of 
simulation  classification  was  defined  as  the  ability  to 
handle  and  safeguard  secure  information  in  accordance  with 
DoD  security  regulations  and  instructions.  All  model 
scenarios  used  were  unclassified.  This  trait  was  defined  to 
allow  greater  range  of  the  capability  hierarchy  that  was 
applied  across  M&S  tools.  Simulations  equipped  with 
encryption  and  decryption  devices  added  functionality  and 
increased  flexibility. 

Jb.  Export/Import  Abilities. 

Export/import  abilities  in  M&S  tools  were  defined 
as  the  ability  to  transfer  scenario  files  from  one 
simulation  to  another.  The  information  extrapolated  needed 

to  be  in  a  useful  form  as  to  enable  cross  simulation 
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interoperability.  These  "ilities"  were  an  extension  of 
program  considerations  in  that  data  from  other  sources  may 
be  needed  to  model  and  simulate  scenarios.  The  focus  was  to 
have  M&S  tools  that  had  the  capability  to  handle  specific 
elements  of  available  information  be  used  to  enhance 
simulation  execution.  There  are  different  forms  of  model 
data  that  can  be  exchanged  between  simulations  and  were 
referred  to  as  databases.  Databases  were  composed  of  single 
entities  that  represented  systems  defined  by  users.  They 
were  also  defined  as  the  object  files  of  the  environment 
effects.  Imagery  data  imported  into  a  simulation  was 
grouped  in  databases  trait  because  the  form  taken  by  the 
information  imported  was  in  most  cases  a  database  object  in 
the  software. 


c.  Adjust  Abilities 

The  majority  of  "model  ability"  in  M&S  tools  came 
from  having  the  ability  to  adjust  parameters  and  settings  of 
a  model.  Adjust  Abilities  are  the  user  defined  properties 
that  represented  the  modeled  system  characteristics.  This 
section  was  critical  to  physically  representing  a  SBE  in  a 
virtual  environment.  The  following  traits  were  a  collection 
of  observed  functionalities,  not  a  comprehensive  listing  for 
M&S  tools  to  be  analyzed  by.  Figure  11  shows  the 
hierarchical  structure  for  Adjust  Abilities. 


62 


Adjustab¬ 

ilities 


Figure  11.  Adjust  Abilities  Hierarchy  Branches. 

(1)  Systems.  System  traits  described  in 
Table  5  were  a  limited  scope  of  capabilities  that  M&S 
possessed.  Simulations  were  measured  on  presence  of 
functionalities  and  not  performance.  The  capability 

hierarchy  was  defined  to  have  the  following  system  traits 
which  include  basic  system  properties.  These  were  available 
for  user  to  adjust  as  needed  from  model  to  model  or 
situation  to  situation. 
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System  Traits 

Functionality 

Definition 

Multiple  Attributes 

Model  properties  that  control  actions  of  units  based  on 
resolution.  Provide  flexibility  of  users  to  model 
multiple  interaction  decision  points. 

Model  Basic  Physics 

Interaction  of  model  in  simulation  environment  that  effect 
movement  and  motion.  SBE  models  needed  to  float  in  water 
and  be  affected  by  wind,  sea  state,  and  shore  transitions. 

Refueling  Capabilities 

Logistic  requirements  modeled  to  measure  performance  and 
usages . 

Movement  Parameters 

Model  scenario  requirements  specified  and  limit  entities 
motion/actions  in  the  simulation. 

Mode  Selection 

Two  modes  of  movement  for  a  SBE  model.  Sea  Mode  and 

Hover . 

Clone  /  Copy  Function 

The  ability  of  an  M&S  tool  to  create  copies  or  multiple 
entities  with  the  same  properties  and  attributes.  Provide 
scalability  of  the  model  to  increase  SBE's  used  in  a 
scenario . 

Military  Operations 

For  use  in  the  DoD,  M&S  tools  model  joint  operations  and 

have  capabilities  to  handle  classic  offensive  and 

defensive  actions.  The  following  functionalities  were 

defined  in  the  hierarchy  as  military  operations. 

Guard  -  Stay  in  position  and  protect  units  or  area 
surrounding  location. 

Patrol  -  Movement  of  entity  to  search  and  protect  units  or 
area  surrounding  designated  location. 

Orbit  -  Continue  repeated  movement  on  designated  path  in 
any  geometer  shape. 

Attack  -  Perform  actions  to  other  entities  to  affect  their 
status . 

Flee  /  Run  -Detect  an  attack  from  a  hostile  force  and  be 
able  to  decide  on  withdrawing  from  the  engagement 
based  on  user  predefined  limits. 

Grouping  Functions  -  Multiple  entities  act  together  in  un- 
nascence  to  perform  a  single  goal. 

Inter  Communications  -  Entities  communication  with  each 
other  during  simulation. 

Remain  in  place  -  Entities  ability  to  decide  to  remain  in 
place  or  be  directed  to  by  attributes. 

Waypoint  selection  -  User  defined  weapon  selection. 

Unit  operations  -  High  resolution  of  entity  actions  that 
enable  single  units  to  act  independently.  Provides 

scalability  to  model. 

Table  5.  System  Traits  Definition. 
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(2)  Environment.  Environmental  factor 
starts  to  increase  importance  on  "model  ability"  of  T- 
craft' s  capabilities  as  greater  forces  are  applied.  The 
environment  traits  defined  were  not  designed  to  limit  M&S 
capabilities  in  other  areas  of  simulation,  but  rather 
address  factors  on  land,  sea,  and  in  the  air  with  reference 
to  a  SBE .  M&S  tools  were  measured  for  presence  of  factors 
in  this  comparison  study. 

There  were  three  environmental  traits  defined 
in  the  capability  hierarchy:  terrain,  ocean  topography,  and 
forces.  The  first  trait,  terrain,  was  at  a  minimum  two 
dimensional  (2D)  that  could  model  traditional  warfare. 
There  were  three  functionalities  associated  with  terrain: 
surface  configuration,  natural  and  man-made  feature 
representation.  The  ability  of  users  to  create  a  terrain  in 
simulations  was  needed  to  develop  custom  scenarios.  Surface 
configuration  functionality  enabled  users  to  build  and 
populate  terrain  surfaces  with  a  variety  of  objects.  Use  of 
terrain  objects  were  dependent  on  flexibility  of  the 
simulation  to  accept  or  create  those  program  objects.  These 
objects  had  the  ability  to  be  natural  or  man-made  to  present 
a  realistic  environment. 

The  second  trait,  oceanographic  modeling, 
applied  to  use  of  ocean  depths  that  were  needed  in  a  naval 
environment.  The  ability  to  model  contour  depth  data  was 
used  for  the  addition  of  submarine  operations  on  the 
scenario.  Water  depth  was  also  needed  for  operations  of 
naval  assets  near  the  shore.  M&S  tools  handled  the  case  of 
ships  running  aground  in  shallow  water.  These  points  were 
eclipsed  by  the  need  of  SBE's  to  shift  from  transit  mode  to 
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hover  mode  at  certain  ranges  from  the  shore.  Modeling  the 
water  features  were  used  for  T-craft  to  meet  mode  shifting 
requirements  in  the  scenario. 

Third,  M&S  tools  modeling  SBE's  were  able  to 
model  sea  state  and  wind  effects  within  the  scenario.  Sea 
state  was  defined  as  the  level  of  effects  from  water  motion 
applied  to  T-craft  movement  and  survivability.  The  wind  was 
defined  as  the  amount  of  force  used  to  slow  or  push  T-craft 
in  the  simulation  environment.  The  capability  hierarchy 
analyzed  M&S  tools  for  the  presence  of  sea  state  and  wind 
effects  on  entities. 

d.  Measures  of  Performance 

Users  were  able  to  select  and/or  create  MOPs 
within  a  scenario,  which  allowed  for  analysis  of  specific 
factors.  Simulation  results  were  likely  to  be  used  by 
decision  makers  to  gain  insights  into  system  capabilities, 
thus  enabled  users  to  narrow  their  search  in  collection  data 
methods.  The  three  MOPs  that  were  defined  in  the  hierarchy 
correspond  to  Paragraph  B,  above.  Simulations  were 
determined  to  have  an  MOP  "ilities"  if  the  yielded  output 
data  was  user  defined  measures  that  related  to  measures  of 
survivability,  transit  times,  and  cargo  transfer. 

e.  Resolution 

The  factors  associated  with  the  Basic  and  Advanced 
Scenarios  called  for  a  high  resolution  model.  The  level  of 
resolution  was  measured  as  the  capability  to  model  T-craft 
force  levels  (Single  vs.  Multiple  units)  .  The  M&S  tools 
used  in  this  research  were  examined  to  determine  what 
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resolution  capabilities  were  present  to  see  if  a  single  unit 
was  modeled  with  individual  actions.  Future  scenarios  may 
require  the  use  of  multiple  SBE's  with  a  high  resolution. 
The  "ilities"  may  be  useful  to  decision  makers  in 
acquisition  of  SBE  technology. 

2 .  Architectural  Design 

Simulation  program  design  was  extremely  important  in 
the  wide  use  M&S  tools  in  the  DoD.  There  are  several  design 
issues  that  must  be  addressed  early  on  in  the  progression  of 
an  M&S  tool  to  pertain  directly  to  its  usability. 
Standardization  of  functionalities  is  crucial  for  users  to 
be  able  to  understand  simulation  processes.  Just  as 
important  as  interface  standards  may  be  a  background  of 
simulation  conception.  DoD  protocol  requirements  for  M&S 
have  put  standardization  of  simulation  at  the  forefront  of 
M&S  development.  Interoperability  of  M&S  tools  enable 
higher  levels  of  computation  to  be  performed  adding  to 
application  flexibility  throughout  M&S.  Figure  12  shows  the 
hierarchical  structure  for  Architectural  Design. 
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Figure  12.  Architectural  Design  Hierarchy  Branches. 

a.  Federate  Capable 

Federate  capability  was  defined  as  "ilities"  where 
simulations  were  integrated  into  a  multiple  code  federation: 
A  federate  is  a  model  networked  into  a  HLA  application  (DoD, 
1998)  .  There  are  three  traits  that  were  derived  from 
federations:  current  DoD  regulations  on  M&S 
interoperability,  reusability  of  models,  and  program 
history.  M&S  tools  that  were  federation  capable  increased 
their  use  in  DoD.  This  added  to  a  model's  flexibility  to 
simulate  SBE  scenarios.  The  use  of  compatible  simulation 
code  allowed  for  the  rapid  exchange  of  information  across 
M&S  tools.  Program  history  was  simply  defined  as  the  access 
to  dates  and  historical  references  to  model  uses. 

(1)  High  Level  Architecture  (HLA)  .  HLA  is 
the  standard  protocol  for  DoD  M&S.  M&S  tools  were 
considered  for  the  presence  of  HLA  protocol,  not  merely 
computability.  HLA  is  a  strong  measure  of  flexibility  which 


68 


allowed  for  incorporation  of  M&S  tools  with  DoD  established 
models  further  validating  the  model,  as  well  as  the  ability 
to  import  current  models  being  used  for  analysis. 

(2)  Reusability.  Reusability  was  defined  as 
the  ability  of  a  model  to  be  recycled  into  future  M&S 
capabilities.  The  development  of  M&S  tools  is  costly  and 
time  consuming.  Simulations  like  Combat  XXI  have  reused 
existing  code  and  modified  it  to  fit  into  a  federate  that 
can  then  handle  a  boarder  range  of  scenarios.  This  allows 
for  further  comparisons  of  traits  among  M&S  in  this 
hierarchy  to  determine  flexibility. 

Jb.  Program  Considerations 

Given  that  M&S  tools  may  handle  secure 
information,  an  important  consideration  to  architectural 
design  was  the  flexibility  of  simulation  features.  M&S 
tools  were  measured  on  three  aspects  of  programming.  An 
inspection  of  six  M&S  tools  was  conducted  to  record  if  the 
programming  code  was  open  sourced  or  proprietary.  This  was 
important  to  understanding  and  believing  the  validity  of 
simulations.  The  magic  black  box  effect,  where  only  inputs 
and  outputs  are  handled  without  a  clear  understanding  of 
underlying  model  algorithms  and  processes,  does  not  assist 
DoD  components  if  processes  are  not  full  accessible.  The 
second  trait  was  the  capability  of  a  simulation  to  input 
operational  scenario  data.  This  capability  was  used  to 
decrease  set-up  and  execution  times.  The  ability  of  a 
simulation  to  import  object  libraries  is  a  requirement  to 
being  HLA  capable.  Therefore,  flexible  simulations  should 
possess  both.  The  third  was  the  auto-save  and  recover  trait 

that  also  assisted  in  set-up  and  execution  times. 
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3. 


Stochastic  Process 


Stochastic  processes  were  defined  in  the  capability 
hierarchy  as  simulation  characteristics  that  were  not 
deterministic.  These  processes  were  extremely  difficult  to 
describe  and  define,  and  were  not  limited  to  a  narrow 
definition.  This  did  not  exclude  the  need  to  have 
simulations  have  stochastic  characteristics.  M&S  tools  were 
measured  on  how  well  the  model  allowed  for  entities  to  react 
to  the  scenario  given  movement  and  attribute  inputs  by 
users.  Therefore,  the  only  "ilities"  that  was  listed  under 
stochastic  processes  was  script  ability.  The  scenarios  were 
dominated  by  naval  operations  which  required  special 
consideration  to  produce  the  proper  outcomes. 

a.  Scriptable 

Scriptable  simulations  were  defined  in  the 
hierarchy  as  having  abilities  to  simulate  the  model  in  the 
same  method  but  obtained  varying  results.  The  Basic  and 
Advanced  Scenarios  were  based  in  the  same  environment,  with 
the  same  routes  and  areas  of  operations.  Having  the  same 
starting  point  was  useful  in  analysis  but  problematic  in 
deterministic  simulations.  There  were  four  traits 
associated  with  script  ability;  user  defined  scriptable 
scenarios.  Next-event  models,  time-step  models,  and  random 
variables  and/or  Markov  principles.  Scriptable  was  defined 
as  the  ability  of  users  to  predetermine  movement  of  entities 
by  waypoint  or  attribute  methods . 

(1)  Next-event/time-step  models.  M&S  tools 
fell  into  one  of  these  categories,  both  of  which  had 
strengths  and  weaknesses.  The  trait  was  defined  by  the 
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simulation  being  either  type.  The  properties  of  Next-event 
and  time-step  simulations  provided  the  flexibility  that  SBEs 
scenarios  utilize. 

(2)  Random  variables  and/or  Markov 
principles.  By  extension  of  stochastic,  a  simulation  should 
posses  some  degree  of  randomness.  This  trait  was  defined  as 
a  simulation  that  had  random  variable  to  produce  pseudo 
random  actions  within  the  iterations.  Markov  chains 
processes  were  made  of  random  changes  that  depend  on  current 
states  of  the  entities  that  entered  a  stable  state. 

H.  SCALABILITY 

Scalability  was  defined  as  the  capability  to  regulate 
any  given  object's  dimensions.  Dimensions  referred  to  the 
different  functionalities  of  simulation  in  this  context. 
The  ability  of  an  M&S  tool  to  adjust  to  the  conditions 
within  the  scenario  was  crucial  to  exploring  the  solution 
space.  A  scalable  simulation  enabled  users  to  adjust  force 
level  parameters,  as  well  force  on  force  engagement.  These 
two  extremes  often  were  not  feasible,  but  certain  degrees  of 
freedom  coincided  with  each  other.  The  first  characteristic 
of  scalability  was  adjudication,  which  referred  to  the 
interactions  of  units  with  a  given  scenario.  The  user  was 
able  to  select  or  adjust  interactions  of  elements  in  the 
simulation  to  judge  its  importance  to  the  results.  Figure 
13  shows  the  hierarchical  structure  for  Scalability. 
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The  second  characteristic,  variation,  pertained 
directly  to  resolution  of  a  simulation.  Variation  in  force 
levels  were  linked  to  scenario  modeling  and  were  often 
adjustable  within  scenario  settings.  SBE  Simulation 
provided  the  user  with  the  ability  to  vary  resolution  within 
the  scenario  along  with  providing  controls  for  expected 
results.  The  adjustable  traits  of  this  characteristic  that 
were  used  to  define  the  capability  of  a  scalable  simulation 
are  delineated  in  Appendix  A. 

1 .  Variation 

Variation  of  M&S  tools  in  the  capability  hierarchy  was 
defined  different  than  in  traditional  uses,  such  as 
statistics.  This  research  utilized  statistical  analysis  and 
referred  to  both  terms.  Variation  characteristic  was  used 
as  a  method  to  control  numbers  of  units  and  level  of 
interaction  in  a  scenario.  M&S  tools  had  two  traits 
associated  with  user  controls,  adjudication  and  adjust 
abilities.  The  amount  of  scalability  a  simulation  offers  to 
decision  makers  could  provide  insights  into  possible 
solutions  to  capability  gaps. 
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2.  Adjudication 


Adjudication  was  defined  in  the  capabilities  hierarchy 
as  the  methods  to  determine  engagement  status  of  entities 
during  a  simulation.  Simulations  offered  the  user  the 
ability  to  determine  and  select  adjudication  methods.  This 
included  traditional  probabilities  tables,  algorithm 
integration,  and  battle  damage  capabilities.  M&S  tools 
allowed  for  these  interactions  to  be  created  and  stored 
during  simulation.  As  well  as  to  determine  engagement 
results,  there  was  the  ability  to  record  and  display  them. 
This  was  a  scalable  "ilities"  because  its  traits  were 
adjustable.  Figure  14  shows  the  hierarchical  structure  for 
Adj  udication . 


Figure  14.  Adjudication  Hierarchy  Branches. 
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a. 


Attain  Abilities 


M&S  tools  were  defined  to  be  attainable  if  the 
following  functionalities  were  available  for  users  to  adjust 
over  multiple  iterations.  Attainable  was,  in  the  strictest 
sense,  the  internal  workings  of  entities  interactions  with 
other  entities.  The  first  functionality  was  the  ability  of 
a  simulation  to  calculate  results  of  a  scenario's  outcome, 
which  enabled  the  users  to  predetermine  output  data  and 
collect  it  for  analysis.  This  functionality  was  called 
Results  and  used  data  points  that  allowed  for  analysis  of 
the  scenario.  These  were  representations  of  unit 
measurements,  MOP  translations,  and  battle  damage  assessment 
reports.  MOP  translation  meant  that  the  model  parameters 
were  interpreted  in  multiple  ways.  The  second  functionality 
was  the  availability  of  users  to  adjust  engagement  types  of 
code  in  the  model  that  governed  the  interaction  of  entities 
conducted  in  simulation  iterations.  The  types  of  code  that 
was  accessible  were  probability  hit  and  kill  tables,  sensor 
and  weapon  settings,  indirect  fire  capabilities,  sensor 
detection  settings,  and  battle  damage  adjustment  methods. 

b.  Adjustability  Traits 

The  adjustability  traits  listed  in  variation  are 
the  same  as  described  previously  in  the  capability  hierarchy 
under  "model  ability." 


V.  SIMULATION  MODELING 


Modeling  &  Simulation  (M&S)  is  a  power  analysis  tool 
used  by  all  elements  of  DoD.  M&S  provides  decision  makers 
the  ability  to  examine  the  SeaBase  Enabler  (SBE)  in  a 
virtual  environment  to  test  capabilities,  operational 
impact,  and  influence  on  relief  efforts.  The  requirements 
of  SBE  employment  are  discussed  by  those  same  decision 
makers  as  to  what  situation  SBE  could  best  be  served.  M&S 
tools  were  used  to  answer  this  question  by  modeling  possible 
SBE  scenarios.  A  model  was  specifically  developed  for 
representing  the  SBO  to  compare  the  various  M&S  tools  that 
were  available  to  industry  and  academia  alike.  The  T-craft 
was  used  as  a  SBE  for  transportation  of  cargo  to  and  from 
the  SeaBase  Operations  (SBO) . 

The  approval  of  the  T-craft  to  an  acquisition  program 
may  rely  heavily  on  the  role  M&S  plays  in  evaluating  the 
SBE's  capabilities  in  given  scenarios.  The  SBE  model 
developed  was  used  to  compare  M&S  tools  capabilities  to 
determine  simulations  usability,  flexibility,  and 
scalability.  The  scenario  utilized  the  baseline 
capabilities  for  T-craft  to  define  model  parameters.  The 
M&S  tools  provided  performance  data,  which  could  be  given  to 
developers  and  decision  makers  alike.  The  diversity  of 
individual  M&S  tools  was  considered  in  initial  simulation 
selection  over  individual  M&S  tool  capabilities. 
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A. 


SBE  SCENARIOS 


There  were  two  scenarios  types,  Basic  and  Advanced, 
that  were  created  in  this  study  to  address  T-craft 
requirements;  peace  and  war  time  environments.  The  peace 
time  environment  was  modeled  without  the  presence  of  hostile 
forces  to  allow  T-craft  free  transit.  This  was  called  the 
Basic  Scenario  and  enabled  M&S  tools  to  collect  MOPs  data  on 
T-craft' s  capabilities.  The  war  time  environment  introduced 
hostile  forces  to  the  measure  survivability  MOP.  This  was 
referred  to  as  the  Advanced  Scenario.  Between  the  two 
scenarios,  a  wide  scope  of  application  was  designed  for  the 
model  to  deal  with  SBE  real-world  projected  scenarios. 

There  were  four  real-world  scenarios  in  which  the  SBE 
concept  is  projected  to  have  direct  involvement.  First, 
Peace  Keeping  and  Peace  Enforcement  Operations  (PKO)  in  a 
peace-time  setting  are  defined  by  Milan  Vego  as  the 
principle  peace  operations.  These  operations  are  designed 
to  control  and  eliminate  hostilities  using  force  and  regain 
or  maintain  peace.  The  timeframe  is  nominally  after  the 
conclusion  of  major  theater  war  (Vego,  2007) .  This  is  also 
keeping  in  mind  that  all  countries  have  reached  an  agreement 
of  ceasefire.  Second,  Major  Theater  of  War  Combat 
Operations  is  the  series  of  tactical  battles  that  are  used 
to  achieve  operational  objectives.  Actions  are  often 
conducted  parallel  or  sequential  in  accordance  with  the 
operational  plan  (DoD,  2001)  . 

Third  is  Regional  Crisis  Intervention  Operations  that 
are  commonly  centered  on  a  single  nation's  objective  or 
security.  This  is  a  situation  that  develops  quickly, 
creating  the  need  for  diplomatic,  economic,  political,  or 
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military  resources.  The  resources  are  used  to  divert  the 
crisis  and  reestablish  stability.  These  operations  are 
normally  associated  with  low  threat  risks  to  forces. 
Lastly,  there  is  Stability  Operations  that  include  military 
missions,  task,  and  activities  that  occur  in  conjunction 
with  other  nations.  They  are  deployed  to  provide  security, 
services,  and  relief  to  host  nations  during  times  of 
conflict  (DoD,  2001)  .  A  generic  model  was  developed  to 
encompass  elements  from  these  four  operational  concepts. 
The  Basic  and  Advanced  Scenarios  were  designed  to  input  the 
generic  SBE  model  in  a  series  of  simulation  tools  to  compare 
their  capabilities.  This  evaluation  was  based  on  the 
previously  defined  hierarchy. 

B.  T- CRAFT  MODEL 

T-craft  capabilities  were  modeled  like  that  of  current 
amphibious  landing  craft  transferring  cargo  from  the  area  of 
SBO  to  shore  landing  sites.  The  T-craft  concept  is  being 
developed  in  the  vision  of  current  amphibious  transportation 
craft  capabilities  with  a  call  for  technology  to  increase 
key  performance  parameters.  T-craft  is  projected  to  offer  a 
wider  scope  of  operations  (by  being  able  to  transit  500  nm 
at  40+  knots)  than  current  logistic  crafts  are  not  able  to 
fulfill.  This  is  a  capability  that  may  provide  options  for 
military  planners  in  both  non-hostile  and  hostile 
environments.  T-craft  also  provides  the  capability  of 
transiting  from  debarkation  point  fully  loaded.  These 
capabilities  are  truly  game  altering.  They  are  significant 
challenges  to  analysts  and  developers  comparing  SBE's 
against  current  capabilities. 
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The  T-craft  model  was  designed  to  make  cargo  parameters 
flexible,  as  well  as  for  a  time  component  to  measure  transit 
times.  The  generic  model  also  attempted  to  measure  the 
scalability  of  simulations  within  M&S  tools  by  introducing 
hostile  threat  interactions  and  engagements.  Figure  15 
shows  the  battle  space  for  the  T-craft  scenario  that  was 
modeled.  The  area  represented  the  Sea  of  Japan  with  the 
separation  between  land  masses  as  approximately  500  nm  at 
the  widest  point.  This  location  was  selected  based  on  the 
availability  and  model  set  up  of  debarkation  points  along 
the  western  coast  of  Japan. 


Figure  15.  SBE  Modeled  Battle  Space. 
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C.  BASIC  SCENARIO 

The  Basic  Scenario  was  based  on  Regional  Crisis 
Intervention  Operations.  The  SBE  mission  was  designed  to 
provide  relief  aid  (cargo)  and  other  supplies  to  ground 
forces  operating  on  a  peninsula  region  near  the  coast.  The 
debarkation  point  was  notionally  a  sea  port  which 
corresponds  to  Sasebo,  Japan.  A  debarkation  point  is  a 
logistic  hub  where  SBE  are  loaded  with  cargo  for  heavy 
transfer.  The  transit  to  the  SBO  was  approximately  350  to 
400  nautical  miles  (nm)  .  The  battle  space  characteristics 
were  designed  to  test  the  T-craft  high  speed  transit 
capability . 

The  Basic  Scenario  modeled  a  simple  transit  with  two 
phases.  The  first  phase  was  T-craft  transiting  from 
debarkation  point  to  SBO  area.  The  second  phase  was  from 
the  SBO  area  to  a  landing  site  on  the  northern  part  of  the 
peninsula.  The  T-craft  model  used  was  the  same  as  industry 
prototypes  that  created  a  craft  with  desired  capabilities 
and  no  self  defense.  The  Basic  Scenario  was  designed  to 
determine  a  baseline  for  transit  times  and  cargo  load-outs 
that  were  used  to  compare  against  in  the  Advanced  Scenario. 

1.  Non-Hostile  Operations 

T-craft' s  transit  in  the  first  phase  was  designed  to 
have  no  external  forces  acting  on  it.  The  Regional  Crisis 
Intervention  Operations  provided  the  scenario  set  up  that 
enabled  T-craft  to  transit  to  the  SBO  area  without  the 
threat  of  hostile  forces  or  interference.  Given  the 
regional  make  up  of  the  Sea  of  Japan,  the  assumption  that  T- 
craft  could  transit  un-escorted  and  uncontested  was  valid. 


79 


The  T-craft  was  able  to  transit  while  loaded  or  unloaded  and 
varied  transit  speeds  to  allow  for  separate  baseline 
measurements  in  multiple  iterations.  The  experiment  design 
offered  independent  measurements  of  these  factors  to 
possibly  observe  relationships  between  further  studies. 

2 .  Interactions 

The  interaction  of  T-craft  with  the  shore  line  is  a 
significant  physical  problem  being  experienced  by 

developers.  T-craft  capabilities  are  required  to  carry 
large  amounts  of  cargo  and  equipment  but  design 
considerations  are  limiting  landing  capabilities.  The  T- 
craft  is  projected  to  be  able  to  land  on  shore  lines  that 

are  less  than  2  percent  incline.  The  scenario  used  in 

this  study  assumes  there  is  sufficient  shore  line 

supportability  on  the  landing  site  on  the  peninsula. 

3.  Cargo  Transfer 

Cargo  transfers  in  amphibious  operations  and  in  the  SBO 
have  loading  spot  considerations  that  affect  MOPs .  This 

required  waiting  queues  or  time  delays  in  the  scenario 

model.  Time-step  and  DES  handled  this  delay  in  different 
ways  causing  a  variation  in  the  Basic  Scenario  baseline 

measurements.  The  variation  in  simulation  results  were 
assumed  to  not  affect  the  comparison  of  M&S  tools  based  on 
the  definition  of  the  capabilities  hierarchy. 

4 .  Refueling  Requirements 

The  number  of  factors  associated  with  any  given 

scenario  was  exponential  with  the  depth  of  detail  presented. 

A  major  factor  of  military  operations  is  the  logistical 
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support  needed  by  units  in  the  field.  T-craft  logistical 
requirements  were  assumed  to  have  been  adequate.  Fuel 
requirements  were  assumed  to  be  sufficient  for  transits  and 
transfers  in  both  phases  of  the  scenario,  and  that  fuel 
levels  were  not  modeled  for  unit  movement  usage.  This  was 
critical  for  M&S  tools  like  MANA  that  have  no  resource 
measure  capabilities  and  fuel  levels  were  adapted  to  be  used 
as  cargo  levels. 

D .  ADVANCED  SCENARIO 

Non-hostile  environments  were  ideal  for  operation  but 
not  without  the  need  for  tactical  protection.  The  Advanced 
Scenario  was  based  on  PRO  and  Stability  Operations  that 
presented  a  battle  space  that  had  the  potential  for  conflict 
within  the  region.  Political  tensions  could  present  a 
possible  SBE  situation  on  the  peninsula.  The  robust  range 
of  operations  that  were  possible  for  the  area  used  both  an 
Advanced  and  Basic  Scenario  to  measure  MOPs  key  to 
evaluating  SBE  performances  in  a  simulation. 

T-craft  is  being  developed  with  limited  defense 
capability  and  is  susceptible  to  attack  from  the  air  and 
surface.  The  Advanced  Scenario  introduced  hostile  threats, 
using  the  Basic  Scenario  as  the  starting  point.  Surface  and 
air  threats  were  inserted  into  the  first  phase  to  intercept 
T-craft  in  the  first  phase  and  during  SBO  transfer.  Escort 
ships  and  aircraft  were  in  direct  response  to  T-craft' s  lack 
of  self  defense  capabilities.  T-craft  was  escorted  by 
varying  number  of  warships.  Escort's  areas  of  operations 
were  focused  on  protecting  T-craft  in  high  threat  regions 
(first  phase)  of  the  scenario.  The  second  phase  was 


81 


relatively  unprotected  by  escorts  while  T-craft  commenced 
high-speed  runs  into  the  landing  site. 

1 .  Escort  Requirements 

There  were  three  surface  escorts  modeled  that  were 
assigned  to  provide  protection  to  the  T-craft  during  transit 
and  cargo  transfer  in  and  around  the  SBO  area.  This  is 
where  the  hostile  forces  were  generated  and  modeled  to 
patrol.  The  escort  forces  were  varied  from  a  single  escort 
up  to  a  total  of  three  during  specific  runs.  The  number  of 
hostile  forces  was  also  varied  from  a  single  surface  ship  or 
aircraft  up  to  a  total  of  three  surface  and  two  aircraft 
threats.  This  design  allowed  for  a  robust  design  of 

experiments  to  be  utilized  in  the  simulating  the  model  over 
multiple  iteration.  The  varying  of  forces  was  used  as  a 
proof  of  concepts  in  the  MANA  simulation. 

2 .  Interactions 

The  interactions  of  friendly  escorts  in  the  Advanced 
Scenario  were  modeled  with  superior  capabilities.  U.S. 
forces  were  assumed  to  have  valid  overwhelming  capabilities 
compared  to  regional  threats.  The  other  interaction  was 
threat  areas  of  operations  that  limited  hostile  forces 
movement.  The  high  threat  was  assumed  to  be  a  general 
approximation  to  where  they  originate  from  and  not  where 
they  remain  during  simulation  runs.  This  assumption  was 
clearly  observed  in  time-step  models  with  agent  based 
models . 
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3. 


Combat  Survivability 


Combat  survivability  was  highly  variable  based  on 
simulation  settings.  The  critical  aspect  of  measuring 
survivability  was  that  it  could  be  user  defined  and  that  the 
option  was  available.  The  Advanced  Scenario  introduced  this 
MOP  by  adding  hostile  forces  to  the  model.  The  assumption 
for  combat  survivability  was  that  the  damaged  sustained  by 
T-craft  was  probabilistic  and  not  constant  across  M&S 
models.  The  standardization  of  probability  tables  or 
adjudication  methods  was  not  addressed  in  this  research. 
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VI .  RESULTS  ANALYSIS 


This  chapter  presents  simulation  parameters  of  the  six 
M&S  tools  used  for  modeling  a  SBE .  The  SBE  Scenario  was  the 
basis  for  all  models  and  was  implemented  in  slightly 
different  ways  depending  on  the  capabilities  of  the  M&S 
tools  used.  The  SBE  Scenario  issues,  like  collection  of 
MOPs,  modeled  entity  interactions,  and  graphical  interfaces 
that  were  discussed  in  the  previous  chapter  sections.  This 
chapter  listed  the  SBE  Scenario  model  parameters  for  MANA, 
Pythagorus,  NSS,  and  Simkit  that  were  directly  used  in  the 
course  of  my  research.  JCATS  and  Arena  model  results  were 
used  for  comparison  only,  with  no  formal  stating  of  model 
parameters.  The  M&S  models  created  were  functionally 
operational,  with  every  effort  made  to  present  complete 
models.  However,  this  research  comes  with  a  disclaimer  that 
this  was  the  best  attempt  by  a  master' s  degree  student  to 
build  models  for  thesis  work. 

A.  CONCEPTUAL  REPRESENTATION 

The  reproduction  of  a  SBE  Scenario  in  a  computer  based 
model  provided  the  evidence  needed  to  evaluate  each  M&S  tool 
used  for  modeling.  In  both  types  of  simulations  (time-step 
and  next-event)  the  SBE  Scenario  was  modeled  in  relatively 
similar  ways.  This  included  a  SBE  craft,  escorts,  and 
hostile  forces.  Variations  in  M&S  tools  did  not  allow  for 
parameters  of  one  model  to  be  emulated  exactly  in  every 
model,  but  did  allow  for  a  comparison  across  simulations  of 
capabilities.  Two  models,  MANA  and  Simkit,  provided  data 
for  MOPs,  with  limited  collection  and  analysis  efforts. 


85 


Other  M&S  tools  were  merely  observed  to  have  the  capability 
to  produce  MOPs .  Because  data  collection  was  not  the  focus, 
it  was  assumed  to  be  similar  for  the  remaining  simulations 
within  the  given  types.  This  section  details  the 
differences  in  implementation  of  the  SBE  model. 

1.  Survivability  of  T-Craft 

The  survivability  of  T-craft  in  the  SBE  Scenario  relied 
heavily  on  the  scalability  of  each  model.  The  adjudication 
"ilities"  in  the  capability  hierarchy  was  used  to  compare 
how  models  attain  abilities  varied  in  simulating  the  T-craft 
in  the  scenarios  and  if  survivability  was  affected  by 
differences  in  adjudication  controls.  Table  6  lists  the 
similarities  between  M&S  tools. 
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Capability  Hierarchy 

MANA 

PYTH 

JCATS 

NSS 

Simkit 

Arena 

Scalability 

Adj  udication 

Attain  ability 

Results 

Units  of  Measure 

D* 

s 

s 

S 

s* 

s* 

MOP  Translation 

S* 

s* 

D 

D 

D 

D 

User  Defined  Data 

S 

s 

S 

D* 

S 

S 

Battle  Damage 

s 

s 

S 

S 

S 

S 

Engagement  (Access  by 

the  User) 

Probability  Tables 

s 

s 

D* 

D* 

S 

S 

Sensor  &  Weapon 

s 

s 

D* 

D* 

s 

S 

Indirect  Fire 

s 

s 

D* 

D* 

s 

s 

Sensor  Detection 

s 

s 

D* 

D* 

s 

s 

Battle  Damage 

D 

D 

D 

D 

D 

D 

D  -  Difference  in  M&S  tools  used. 

D*  -  Difference  in  M&S  tools  in  same  type. 

S  -  Similar  to  other  M&S  tools  used. 

S*  -  Similar  to  other  M&S  tools  in  same  type. 

Table  6.  Simulation  Similarity  Comparison. 


2 .  Graphic  Representation 

There  were  three  different  representations  of  the  SBE 
Scenario  that  were  available  across  the  types  of 


simulations  . 


The  first  was  the 


classic  sand  box 


representation  that  JCATS  and  NSS  depicted  with  blue  water 
and  brown  colored  land.  This  was  the  traditional  look  of 
M&S  tools  with  which  decision  makers  are  probably  most 
comfortable.  JCATS  and  NSS  also  had  model  controls  on  the 
same  screen  as  the  battle  space  for  the  user  to  visualize 
adjustments.  This  was  completely  different  from  the  other 
models  like  MANA  and  Pythagoras  that  offered  separate 
control  windows  for  agent  attributes.  The  other  difference 
in  simulation  with  MANA  and  Pythagoras  was  that  waypoints 
and  other  control  options  remained  on  the  screen  during 
iterations  of  the  model.  The  last  difference  was  that 
Simkit  and  Arena  models  did  not  offer  any  battle  field 
depiction  for  users.  These  differences  greatly  affected 
capability  hierarchy  evaluations  of  the  M&S  tools. 

3 .  Agent  Based  Modeling 

Use  of  AABM  was  observed  in  four  of  the  six  simulations 
with  Simkit  and  Arena  having  no  capability.  MANA, 
Pythagoras,  JCATS,  and  NSS  had  AABM  elements  that  enabled  a 
stochastic  process  within  the  simulations.  While  JCATS  and 
NSS  used  AABM  algorithms  for  agent  actions,  MANA  and 
Pythagoras  had  AABM  built  in  to  govern  actions  of  their 
entities  in  the  form  of  attribute  settings.  The  SBE 
Scenario  was  modeled  in  both  MANA  and  Pythagoras  with 
similar  settings  but  could  not  be  duplicated.  The  attribute 
settings  were  used  at  a  minimum  to  obtain  results  as  the 
evidence  that  the  different  M&S  tools  did  have  the 
functionalities.  MANA  and  Pythagoras  models  were  different 
even  though  the  modeled  attributes  for  the  T-craft  entity 
were  held  relatively  constant. 
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4. 


Deterministic  Attributes 


Deterministic  attributes  were  meant  to  describe  the 
probability  based  models.  Simkit  and  Arena  were  models  that 
had  no  agent  elements  but  offered  probabilistic  results  to 
the  SBE  Scenario.  These  models  were  limited  to  modeling  the 
scenario  in  DES.  The  models  were  not  deterministic  by 
definition  but  could  be  repetitive  over  multiple  iterations. 
The  other  differences  with  DES  models  were  that  the  scenario 
focused  on  the  processes  within  the  scenario  that  the  other 
four  models  were  not  capable  of  modeling  or  measuring.  DES 
models  modeled  the  delay  interactions  of  the  T-craft  as  it 
moved  from  one  point  or  process  to  another.  Simkit  and 
Arena  modeled  the  loading  and  unloading  of  T-craft  in  the 
SBO  and  the  shore  landings  site,  where  other  M&S  tools 
inserted  constant  delays.  DES's  capability  to 
stochastically  model  the  interaction  characteristics  made 
the  SBE  Scenario  narrower  in  scope  compared  to  the  full 
scenario  models. 

5 .  Simulation  Start 

Time  and  events  were  measured  differently  for  both 
types  of  M&S.  Time-step  based  models  enabled  MOPs  like 
transit  times  and  survivability  where  next-event  based 
models  isolated  cargo  transfers,  which  made  the  SBE 
Scenario,  vary  across  M&S.  The  start  of  simulations  was  the 
only  time  in  which  the  parameters  were  constant.  DES  models 
applied  probabilities  where  designed,  during  every 
iteration.  AABM  applied  probabilities  when  the  agent 
selected  the  path  to  engage  T-craft.  The  stochastic 
properties  of  the  M&S  tools  caused  the  SBE  Scenario  to 
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unfold  rather  quickly  into  multiple  directions  that  could 
not  be  accounted  for  in  data  analysis.  The  M&S  tools 
selected  did  provide  a  wide  range  of  capabilities  that  were 
available . 

B.  TIME -STEP  BASED 

Time-step  based  models  were  centered  on  processing 
events  that  occurred  at  a  given  time  interval.  The  updates 
were  made  to  the  simulation  after  a  process  cycle  of  all 
events  had  been  calculated  and  was  complete.  Time-step 
based  models  processed  all  events  at  every  time  interval  and 
sent  updates  as  needed.  Time-step  enabled  such  models  as 
AABM  to  recalculate  search  algorithms  on  demand  in  a 
stochastic  environment.  The  process  time  grew  as  more 
complex  events  were  added  to  the  model. 

1 .  Joint  Conflict  and  Tactical  Simulation 

The  model  used  in  evaluating  the  capabilities  of  JCATS 
was  created  by  LT  Richard  Jimenez,  U.S.  Navy,  at  the  Naval 
Postgraduate  School  in  the  System  Engineering  department. 
Together  with  LT  Jimenez,  the  SBE  Scenario  was  the  basis  for 
implementation  of  his  SBE  Scenario  into  JCATS  assessment 
that  was  referenced  in  my  research.  Additionally,  his  work 
was  designed  to  provide  a  baseline  model  for  the  SBE 
Scenario  to  test  concept  of  operations  ideas  that  would  be 
used  in  further  data  analysis.  The  Jimenez  Scenario  was 
based  on  the  geographical  east  and  west  coast  of  the  Korean 
peninsula  and  was  modeled  in  a  regional  conflict  setting. 
The  bulk  of  the  research  was  focused  on  T-craft's 
survivability  in  the  SBE  Scenario;  therefore,  the  Basic 
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Scenario  was  not  simulated  due  to  time  constraints  with 
iteration  times  of  the  JCATS  model. 

The  major  difference  in  the  Jimenez  scenario  was  the 
use  of  multiple  T-craft  entities  within  the  simulation  to 
increase  survivability  measurements.  JCATS  was  well  suited 
for  theater  level  simulations  at  a  high  resolution. 
Modeling  a  single  T-craft  was  not  effective  for  JCATS.  The 
T-craft  was  modeled  with  a  higher  resolution.  Future  work 
in  JCATS  could  experiment  with  the  resolution  as  a  resource. 

a.  Parameters 

The  Jimenez  Scenario  used  entities  built  from 
entities  within  the  JCATS  database.  Air  superiority  was 
assumed  in  the  scenario;  hence,  there  were  no  air  units 
modeled.  Escort  units  were  modeled  as  cruiser  and  destroyer 
platforms  and  SBO  units  were  modeled  as  standard  amphibious 
platforms.  Extra  considerations  were  taken  because  of  JCATS 
modeling  requirements  to  properly  create  a  working  model. 
The  first  assumption  was  that  logistic  support  was  available 
without  special  implementation.  U.S.  Naval  auxiliary 
platforms  were  modeled  into  the  Jimenez  Scenario  to  provide 
fuel  and  cargo  for  transfer  to  the  shore  by  T-craft  from  the 
JCATS  database. 

Hostile  forces  were  modeled  as  foreign  destroyer 
and  coastal  patrol  platform  vessels  as  well  as  ground 
forces.  The  ground  conflict  of  the  model  was  not  discussed 
in  this  study  because  the  measurements  of  the  T-craft  were 
collected  prior  to  ground  conflict  occurred  in  the  scenario 
and  therefore  did  not  affect  interactions  at  sea.  The 
initial  settings  of  the  Jimenez  Scenario  started  with  a  sea 
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state  of  1  at  night  with  a  full  moon,  with  weather  effects 
at  a  minimal,  and  hostile  force  capabilities  set  to  10  to  15 


percent  less  than  Escorts.  Figure  16  displays  the  Jimenez 
Scenario  at  simulations  start. 
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Figure  16.  Jimenez  Model  Scenario  at  Simulation  Start. 


Jb.  Design  of  Experiments 

The  Jimenez  Scenario  focused  on  employment  of  the 
joint  force  capability  to  project  power  from  the  sea  to  the 
shore.  Attributes  that  were  varied  were  environmental 
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conditions  and  distance  from  shore  landing  sites.  Table  7 
illustrates  the  simulations  configuration  that  was 


Table  7.  JCATS  Simulation  Design  of  Experiments. 


c.  Data  Analysis 

The  results  of  the  Jimenez  scenario  showed  the 
capability  of  JCATS  to  analyze  the  SBE  scenario  in  a 
different  way  than  other  M&S  tools  used.  The  JCATS  modeled 
the  dual  coastal  approach  of  forces,  which  measured 
logistical  elements  automatically  within  the  scenario. 
JCATS  also  represented  environmental  conditions  differently 
than  NSS  that  allowed  for  measurement  of  transit  times. 
Specific  data  points  were  extracted  on  surface  tactic 
implementation  that  were  outside  the  scope  of  the  Advanced 
Scenario  but  proved  to  show  the  flexibility  of  JCATS  in  the 
evaluation.  Table  8  shows  the  results  of  the  simulation 
runs  conducted  by  LT  Jimenez. 
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JCATS  Simulation  Results 

MOP 

Scenario  1 

Scenario  2 

Mission  Duration 

West 

East 

West 

East 

West 

Transit  to  shore 

landing  site 

* 

* 

7:58 

9:05 

9:48 

Transit  back  to  SBO 

* 

* 

13:20 

18:50 

16:21 

Survivability 

West 

East 

West 

East 

West 

Percent  of  T-craft 

survived  complete 

runs 

4  % 

0  % 

100  % 

96  % 

96  % 

*  No  times  recorded  based  on  T-craft  survival  rate  in  transit  to  shore  landing 

site . 

Table  8.  JCATS  Simulation  Results. 


2 .  Map  Aware  Non-Uniform  Automata 

MANA  was  developed  by  a  New  Zealand  company  Defense 
Technology  Agency  (DTA)  in  2008  as  an  agent-based  model  with 
a  bottom-up  approach  to  warfare.  DTA  researched 
implications  of  chaos  and  complex  theory  in  military 
applications  and  discovered  that  cellular  automaton  models 
produced  results  that  were  different  that  those  of 
traditional  models.  The  limitations  of  traditional  models 
with  areas  like  command  and  control,  situational  awareness 
(SA) ,  and  heterogeneous  forces  fell  short  of  realistic 
results.  The  MANA  program  was  designed  to  introduce  certain 
functionalities  to  the  current  Complex  Adaptive  Systems 
(CAS)  simulations.  MANA  integrates  a  memory  map  to  allow 
for  agents  to  have  share  SA  and  maneuver  around  the  battle 
space  (McIntosh,  Anderson,  &  Lauren,  2007) . 
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In  2000,  MANA,  with  the  Project  Albert,  a  U.S.  Marine 
Corp.  research  development  program,  introduced  three  agent- 
based  models  in  succession:  Irreducible  Semi-Autonomous 
Adaptive  Combat  (ISAAC),  Enhanced  ISAAC  Neural  Simulation 
Tool  (EINSTein) ,  and  Pythagoras  (Bitinas,  Henscheid,  & 
Troung,  2003)  .  The  agent-based  characteristics  made  MANA 
the  most  appealing  of  the  AABM  where  results  could  be 
obtained.  The  bulk  of  the  model  settings  were  in  the 
attributes  of  each  entity.  Event  triggers  were  also 
implemented  to  assist  in  interactions  of  units  to  obtain  the 
proper  MOPs .  The  Advanced  Scenario  attempted  to  reflect 
controlling  sea  lanes  of  communications  by  defending  against 
a  hostile  threat  with  varying  forces.  The  sea  lanes  were 
limited  to  waypoints  in  the  first  phase  of  the  scenario. 

There  were  many  assumptions  in  this  scenario  that 
allowed  the  SBE  to  be  modeled.  The  fuel  function  in  this 
study  was  used  to  model  cargo  transfer  from  the  T-craft 
entity  to  landing  sites.  Refueling  and  logistic  support 
were  assumed  to  be  adequate  and  not  measured.  The  Advanced 
Scenario  did  not  actively  use  coordinated  tactics  by  either 
sides.  The  use  of  MANA  produced  stochastic  results  to 
answer  survivability  questions  posed  by  scenario  objectives. 
MANA  has  a  number  of  available  parameters  like  preference 
settings  towards  enemy  and  friendly  units  that  were 
adjustable  for  modeling  realistic  interactions. 

Resolution  was  an  important  aspect  in  MANA  for  MOP 
studies  where  cargo  was  the  focus  of  a  study.  This  research 
used  MANA  because  of  its  resolution  ability  of  combat 
forces.  The  Advanced  Scenario  was  designed  with  opposing 
forces  and  one  T-craft  transiting  to  the  SBO  area.  Future 
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studies  many  be  modeled  with  multiple  SBE  being  used  to 
transfer  cargo.  The  last  assumption  that  was  made  was  the 
modeled  capabilities  of  forces.  The  Scenarios  depicted  U.S. 
Naval  Forces  as  escort  elements  and  a  generic  third  world 
naval  force  as  the  opposing  force.  All  opposing  forces  were 
modeled  with  a  limited  offensive  capability.  Escort  forces 
were  modeled  with  a  2:1  advantage  in  the  Advanced  Scenario. 

The  results  of  the  Basic  Scenario  were  as  expected; 
however,  the  Advanced  Scenario  introduced  a  higher  degree  of 
stochastic  processes  and  did  not  clearly  provide  statistical 
MOPs  for  survivability.  The  AABM  elements  appeared  to 
contain  more  randomness  that  could  be  accounted  for  in 
attribute  settings.  Another  MOP  was  the  number  of  escorts 
needed  for  T-craft  defense.  Based  on  the  irregular  results 
of  the  survivability  measurement,  the  number  of  escorts  did 
not  correlate  to  the  increase  in  opposing  forces.  A  future 
consideration  could  be  convoy  tactics  to  ensure  that  the 
transfer  of  cargo  is  sufficient.  The  protection  of  cargo 
ships  in  naval  history  could  have  had  applications  in  this 
scenario  where  the  amount  of  supplies  delivered  was  a 
measured  factor. 

a.  Parameters 

The  scenario  parameters  in  the  MANA  model  are 

depicted  in  the  following  section.  There  were  six 

attributes  and  one  general  setting  tab  within  MANA  that  were 

used  to  set  parameters  for  both  the  Basic  and  Advanced 

Scenarios.  The  tabs  were  Battlefield  settings.  General, 

Personality,  Ranges,  Sensors,  Weapons,  and  Algorithm. 

Figures  25  through  43  show  the  SBE  model  set  up  in  the  MANA 

environment  at  the  end  of  the  chapter.  Figure  17  is  the 
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generic  model  set  up  for  the  battle  space  configuration  and 
a  depiction  of  the  Advanced  Scenario.  The  model  dimensions 
were  configured  to  match  the  approximate  area  span  of  the 
geographical  location;  the  scenario  was  based  on  a  500  x  500 
nm  area.  The  terrain  parameter  was  kept  as  a  simple  line  of 
sight  model  that  provided  the  most  general  mode  for 
evaluation  purposes.  The  remaining  settings  were  left  as 
default . 


Figure  17.  MANA  Battlefield  Settings. 

The  first  unit  instance  defined  in  the  Scenarios 
was  the  T-craft.  Figures  25  through  29  show  T-craft 
settings  used  in  the  Basic  and  Advance  Scenarios.  The 
number  of  T-craft  units  remained  constant  at  one  for  all 
simulation  runs.  T-craft  waypoint  flags  are  seen  in  Figure 
17  .  T-craft  weapons  tab  was  not  provided  due  to  the  INP 
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requirements  that  do  not  call  for  defense  capabilities.  The 
weapons  tab  had  Master  Enable  deselected. 

The  second  unit  instance  defined  was  the  escort 
forces  for  T-craft's  transit  to  the  SBO  in  the  first  phase. 
The  number  of  escort  forces  varied  according  to  the  design 
of  experiments.  The  attribute  settings  were  kept  simple  as 
well  for  the  same  reasons.  Figures  30  through  33  show  the 
escort  parameter  settings  that  were  the  same  for  each 
individual  escort  unit.  The  general  configuration  settings 
for  escort  units  used  the  side  name  as  Escorts,  Squad  #3, 
and  varied  the  number  of  agents.  The  initial  orientation 
was  designed  to  remain  constant  for  all  entities. 

The  third  unit  instance  was  hostile  surface 
forces,  which  are  represented  in  Figures  34  through  38.  The 
same  general  configuration  was  used  as  Escorts  with  the 
naming  of  hostile  forces.  The  fourth  unit  instance  was  a 
hostile  air  threat  that  was  modeled  with  considerable 
advanced  capabilities  over  surface  forces.  This  advantage 
was  represented  by  increased  speed  capability.  Figures  39 
through  43  show  the  hostile  air  threat  model  parameters. 
Squad  #  6  was  used  and  the  side  options  were  selected  to 
match  those  of  the  hostile  surface  forces.  The  last 
parameter  that  was  selected  was  the  simulation  stopping 
criteria.  This  parameter  was  set  to  T-craft's  end  goal. 

Jb.  Design  of  Experiments 

The  solution  space  for  the  model  was  large  and 
required  extensive  analysis  of  data  to  examine  all  possible 
combinations.  According  to  Cioppa  (2002),  the  concept  of 
Latin  hypercubes  with  orthogonality  improved  space  filling 
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properties  of  experimental  design.  The  application  of  nearly 
orthogonal  Latin  hypercubes  (NOLH)  reduced  experimental 
iterations  to  find  key  correlation  elements  of  a  simulation. 
The  NOLH  method  was  applied  to  decrease  the  number  of 
iterations  needed  to  determine  relations  between  the  three 
MOPs  . 

There  were  three  factors  in  the  Basic  Scenario 
that  were  varied.  The  first  variable  was  speed  of  the  T- 
craft  which  was  represented  in  MANA  as  an  arbitrary  factor 
within  the  model.  MANA  provided  for  the  selection  of  two 
speeds  for  the  T-craft  entity.  The  second  speed  was  double 
the  first  to  show  the  capability  T-craft  had  to  achieve  in 
capability  3.  The  additional  factor  was  the  number  of 
transfer  trips  scripted  to  the  shore  with  a  maximum  of  three 
for  the  T-craft  to  delivery  cargo  in  the  second  phase. 
Table  9  shows  the  NOLH  design  employed  for  the  Basic 
Scenario.  A  single  variable  setting  or  trail  was  iterated 
for  50  replications. 
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Basic  Scenario 

First  Phase 

Second  Phase 

Speed 

Cargo  Rate 

Speed 

Cargo  Rate 

Trips  to 
Shore 

200/100 

-20 

200/100 

-20 

3 

200/100 

-10 

200/100 

-10 

3 

200/100 

-10 

200/100 

-10 

1 

200/100 

-15 

200/100 

-15 

2 

400/400 

-20 

400/400 

-20 

2 

400/400 

-10 

400/400 

-10 

2 

400/400 

-10 

400/400 

-10 

3 

400/400 

-20 

400/400 

-20 

3 

400/400 

-15 

400/400 

-15 

2 

400/400 

-5 

400/400 

-5 

1 

400/400 

-15 

400/400 

-15 

1 

400/400 

-15 

400/400 

-15 

3 

400/400 

-10 

400/400 

-10 

2 

200/100 

-5 

200/100 

-5 

2 

200/100 

-15 

200/100 

-15 

2 

200/100 

-15 

200/100 

-15 

1 

200/100 

-5 

200/100 

-5 

2 

Table  9.  NOLH  Design  of  Experiments  for  Basic  Scenario. 


The  Advanced  Scenario  introduced  varying  numbers 
of  escort  and  opposing  forces  to  T-craft's  transit.  In  an 
effort  to  counter  the  opposing  forces,  escort  ships  were 
positioned  ahead  of  T-craft's  transit,  which  allowed  for 
protection  of  the  transit,  as  shown  in  Figure  17.  Expanding 
on  Table  9,  Table  10  shows  the  factors  used  to  simulate  the 
SBE  model  in  both  phases. 
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Advanced  Scenario 

Speed 

Cargo 

rate 

Trips 
to  shore 

Escorts 

Surface 

Threats 

Air 

Threats 

200/100 

-20 

3 

2 

2 

2 

200/100 

-10 

3 

2 

1 

1 

200/100 

-10 

1 

2 

2 

2 

200/100 

-15 

2 

3 

2 

1 

400/400 

-20 

2 

1 

2 

1 

400/400 

-10 

2 

3 

1 

2 

400/400 

-10 

3 

2 

3 

1 

400/400 

-20 

3 

3 

3 

2 

400/400 

-15 

2 

2 

2 

2 

400/400 

-5 

1 

2 

3 

1 

400/400 

-15 

1 

2 

3 

2 

400/400 

-15 

3 

3 

2 

1 

400/400 

-10 

2 

1 

2 

2 

200/100 

-5 

2 

3 

2 

2 

200/100 

-15 

2 

1 

3 

1 

200/100 

-15 

1 

2 

1 

2 

200/100 

-5 

2 

1 

1 

1 

Table  10.  NOLH  Design  of  Experiments  for  Advanced  Scenario. 


The  representation  of  transferred  cargo  was 
modeled  in  MANA  by  using  triggers  that  simulated  the 
increase  of  goods  at  the  shore  landing  site.  The  shore 
landing  site  enabled  a  trigger  when  T-craft  was  within  range 
and  triggered  the  commencement  of  cargo  transfer.  My  Fuel 
Usage  Rate  simulated  large  amounts  of  cargo  transfer.  These 
parameters  were  in  shown  in  Ranges  Settings  when  the  Fuel 
Out  trigger  was  selected. 

c.  Expected  Results 

The  expected  results  in  the  Basic  Scenario  were 
predicted  to  be  straight  forward  measuring  the  statistical 
outcomes  of  transit  times  and  cargo  transfer.  The 
survivability  of  T-craft  in  the  Advance  Scenario  was 
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affected  by  the  increased  stochastic  processes.  The  third 
measured  value  was  the  number  of  escorts  needed  to  provide 
protection  to  the  T-craft  unit.  This  was  proportional  to 
the  number  of  hostile  forces  in  the  area. 

d.  Data  Analysis 

MANA  provided  MOPs  in  generic  terms,  which  allowed 
for  a  capabilities  evaluation  of  the  simulation  to  be  made. 
The  representations  of  time  and  cargo  values  did  allow  for  a 
translation  to  various  units  and  measures.  The  generic 
units  were  reported  to  illustrate  the  versatility  of  the 
simulation  for  combat  models.  The  survivability  factor  of 
T-craft  in  the  Advanced  Scenario  measured  a  probability  of 
survival.  The  results  were  provided  here  to  illustrate  the 
capability  of  MANA  to  yield  MOPs. 

The  following  results  were  obtained  from  the  Basic 
Scenario  and  list  the  average  transits  times  with  varied 
number  of  deliveries  based  on  the  design  of  experiments. 
The  average  amount  of  cargo  transferred  to  the  shore  site 
was  listed  by  varied  rate  transfers.  Again,  all  trials 
conducted  in  MANA  were  replicated  50  times  for  statistical 
analysis.  Table  11  shows  the  results  from  the  Basic 
Scenario . 


102 


Basic  Scenario  Results 

Speed 

Cargo  Rate 

Time  +  SD  (sec) 

Cargo  +  SD 
(gal) 

200/100 

5  (3  Trips) 

457.84  +  8.29 

398.60  +  177.27 

200/100 

10  (3  Trips) 

445.38  +  7.30 

1173  +  316.74 

200/100 

20  (3  Trips) 

446.38  +  8.48 

2295.2  +  780.76 

400/100 

10  (3  Trips) 

200.04  +  4.78 

465.0  +  148.07 

400/100 

15  (3  Trips) 

201.20  +  5.77 

702.10  +  253.51 

400/100 

20  (3  Trips) 

200.5  +  4.81 

893.6  +  253.51 

200/100 

5  (2  Trips) 

347.76  +  5.04 

364.4  +  110.3 

200/100 

5  (2  Trips) 

336.4  +4.90 

328.70  +  108.78 

200/100 

15  (2  Trips) 

338.36  +  5.21 

1001 . 4  +  331 . 11 

400/100 

10  (2  Trips) 

160.82  +  3.55 

295.8  +  117.21 

400/100 

10  (2  Trips) 

167.76  +  4.52 

325.2  +  126.59 

400/100 

15  (2  Trips) 

157.72  +  3.50 

441 . 6  +  180 . 87 

400/100 

20  (2  Trips) 

164.1  +  3.94 

558.0  +  168.85 

200/100 

10  (1  Trips) 

283.28  +  13.81 

331.2  +  131.59 

200/100 

15  (1  Trips) 

280.84  +  13.17 

542.4  +  291.47 

400/100 

5  (1  Trips) 

136.32  +  1.63 

97.6  +  33.12 

400/100 

15  (1  Trips) 

134 .96  +  2.09 

307.20  +  138 . 15 

Table  11.  Basic  Scenario  Results. 


Table  12  shows  the  results  from  the  Advanced 
Scenario  which  lists  the  distribution  of  survival  percent 
for  T-craft  in  the  given  replications.  The  distribution  of 
Surface  and  Air  threats  represented  the  number  of  entities 
that  were  built  into  the  scenario  run  for  each  category. 
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Advanced  Scenario  Results 

Speed 

Cargo 

Rate 

Escorts 

SURF 

Threat 

AIR 

Threat 

Survive  % 

200/100 

20 

3 

2 

2 

62 

200/100 

10 

3 

2 

1 

48 

200/100 

10 

1 

2 

2 

52 

200/100 

15 

2 

3 

2 

48 

400/100 

20 

2 

1 

2 

80 

400/100 

10 

2 

3 

1 

54 

400/100 

10 

3 

2 

3 

68 

400/100 

20 

3 

3 

3 

70 

400/100 

15 

2 

2 

2 

74 

400/100 

5 

1 

2 

3 

64 

400/100 

15 

1 

2 

3 

84 

400/100 

15 

3 

3 

2 

50 

400/100 

10 

2 

1 

2 

90 

200/100 

5 

2 

3 

2 

42 

200/100 

15 

2 

1 

3 

76 

200/100 

15 

1 

2 

1 

54 

200/100 

5 

1 

1 

1 

64 

Table  12.  Basic  Scenario  Results. 


The  mean  probability  of  survival  for  T-craft  was 
63.53  +  14.06%,  which  was  less  than  80  percent  of  an 

acceptable  survivability  rate. 

e.  Select  Capabilities 

Use  of  the  MANA  program  showed  that  it  was 

possible  for  the  SBE  Scenario  to  be  represented  in  a 
computer-based  model.  MANA  provided  a  set  of 

characteristics  and  parameters  in  the  form  of  personal 
settings  that  were  used  for  modeling  the  T-craft  to  explore 
the  capabilities  that  were  desired  for  a  SBE.  Desired 

results  were  obtained  from  fairly  simple  agent  settings, 
which  made  it  user  friendly.  The  graphical  representation 
provided  a  powerful  capability  for  visualization  of  the 
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battle  space.  MANA  was  a  stand-alone  agent-based  M&S  tool 
that  could  be  used  in  combination  with  a  federation,  for 
future  T-craft  simulation. 

MANA  was  useful  for  collect  data  from  the  model. 
The  data  obtained  from  the  replications  of  Scenarios  were 
directly  measured  to  determine  statistical  information.  The 
results  were  used  to  show  the  presence  of  an  accuracy 
functionality.  The  Basic  Scenario  results  indicated  an 
apparent  relationship  between  the  increased  transfer  rate 
and  speed.  One  limitation  to  the  MANA  results  was  that  for 
11  of  the  17  measurements,  there  was  a  large  amount  of 
variability  among  the  cargo  transfer  time,  such  that  the 
standard  deviation  values  were  as  large  as  half  of  the  mean 
values.  Typically,  a  modest  amount  of  variability  would  be 
indicated  by  a  standard  deviation  that  is  less  than  20 
percent  of  the  mean  value. 

MANA  is  not  an  open  source  program.  A 
disadvantage  of  this  was  that  documentation  was  not 
available  to  users.  The  MANA  user  manual  was  available 
within  the  downloaded  source  code,  but  was  outdated  for  both 
MANA  version  4  and  version  5.  There  were  several  display 
and  control  settings  that  did  match  and  were  not  explained 
in  the  user  manual.  This  was  only  a  minor  inconvenience. 

One  difficulty  to  building  the  SBE  scenarios  was 
the  determination  of  weapons  effectiveness  and  defensives 
for  forces  that  allowed  for  favorable  exchange  rates,  while 
applied  red  force  movements  were  realistic.  The  other 
difficulty  was  modeled  T-craft  capabilities  had  to  be 
maintained  to  conform  to  desired  ONR  requirements.  The  T- 
craft  speed  was  overly  extended  to  illustrate  the  extreme 
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advantage  it  had  over  conventional  forces.  This  was  done  by 
setting  T-craft's  speed  to  double  that  of  hostile  forces. 

One  disadvantage  to  the  usability  MANA  was  the 
inability  to  transfer  created  scenarios  to  other  models. 
The  TCP  and  UDP  output  streams  were  useful  for  combining 
simulation  but  did  not  allow  analysis  data  to  be  collected 
in  an  effective  way.  In  the  Basic  Scenario  cargo 
measurement  were  made  from  multiple  Excel  spreadsheet 
entries  taken  from  separate  files  across  the  multiple  run 
output  files.  This  was  time  consuming  and  not  useful  for 
quick  and  rapid  analysis  of  key  MOPs . 

3 .  Pythagoras 

Pythagoras  was  developed  in  conjunction  with  Project 
Albert  in  2000  as  previously  discussed,  in  an  attempt  to 
model  human  factors  in  simulation  environments.  It 
introduced  capabilities  like  soft  decision  rules  for  agents, 
dynamic  "sidedness, "  alterations  to  behavior  during  run 
time,  and  nonlethal  weapons  (Bitinas,  Henscheid,  &  Troung, 
2003) .  A  design  criterion  for  Pythagoras  was  the  ability  to 
run  the  simulation  in  batch  mode  for  data  farming.  The 
usability  of  Pythagoras  extended  over  platforms  because  of 
its  JAVA  based  software.  It  was  offered  soft  decision  rules 
that  were  adjustable  by  the  users  to  input  variation  in 
agent  actions.  The  agent's  processes  did  review  their 
actions  in  a  predetermined  order,  which  allowed  for  some 
advantages  and  disadvantages  to  the  agent  interactions. 

Pythagoras  was  included  in  this  research  for  comparison 
of  multiple  AABM.  It  has  differences  that  are  discussed  in 
this  section.  Replications  of  the  SBE  scenario  were  not 
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needed  for  this  model  based  on  the  similarity  with  MANA. 
Simulation  results  were  predicted  to  match  those  of  MANA. 
The  SBE  Scenario  modeled  was  sufficient  for  comparison  of 
the  M&S  capabilities  in  this  research. 

a.  Parameters 

The  Pythagorus  modeled  scenario  parameters  are 
depicted  in  the  following  section.  There  were  multiple 
attribute  tabs  that  were  used  to  set  parameters  for  both  the 
Basic  and  Advanced  Scenarios.  The  tabs  were  Overview, 
Terrain,  Weapon,  "Sideness,"  Sensor,  Comms,  Agent,  Attribute 
Changer,  Alternate  Behavior,  and  MOE .  Figures  44  through  57 
show  the  SBE  model  basic  model  set  up  in  the  Pythagoras 
environment . 
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Comms  Agent 

Attribute  Changer 

Alternate  Behavior  MOE 

|  Overview 

Terrain 

Weapon  |  Sidedness 

Sensor 

Scenario  Properties 

Number  Time  Steps: 

1  SOO  I 

Random  Seed 

ElU 

Random  Index: 

□j 

Overview  Properties 


Scenario  Description: 


PythagorasFiles 
SeaBasing  Enabler  Scenario 


This  simulation  will  moOel  the  SBE  operating  in 
Non-Hostiie  &  Hostile  environment 


Location:  Sea  of  Japan 


Figure  1 8 . 


Pythagoras  Model 


Overview . 
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Position:  |x=58Y-184~  |  Time  Step:  I  500  |  j  Seed:  1  1  I  |  Index:  I  1  I 


Figure  19.  Pythagoras  Map  Overview. 


There  were  three  unit  instances  used  in  the 
Pythagoras  model.  The  first  was  the  blue  agent  that 
represented  T-craft.  The  blue  agent  force  parameters 
settings  are  shown  in  Figures  44  through  48.  The  second 
instance  was  red  agent  forces  that  are  found  in  Figures  49 
through  51.  Shore,  cargo,  and  MOE  parameters  are  shown  in 
Figures  52  through  57.  These  figures  showed  specific 

changes  made  to  the  default  settings.  A  majority  of  the 
instance  settings  were  similar  for  all  units  and  remained 
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constant.  Figure  20  lists  the  minor  settings  that  were  not 
shown  in  the  basic  model  figures  and  remain  constant. 


Basic  Properties 


Terrain  Dimension  -  500  X  500 

Terrain  Properties  -  Concealment  =  0.0/Mobility  =  1.0/Protection  =  0.0 
Features  Properties  -  Not  Used 


Basic  Properties 


Restoration  Weapon  -  Default 
Weapon  Targeted  Against  -  Enemies 


PK  Properties  -  Default  Settings 


Default  Settings 


Default  Settings 


Default  Settings 


Blue  Agent 


Terrain  Preference  -  Default  Settings 
Weapon  Possession  -  Not  Used 
Engagement  Desire  -  Default  Settings 
Sensor  Possession  -  Default  Settings 
Comms  Possession  -  Default  Settings 
Side  Property  -  Blue 
Attributes  -  Not  Used 


110 


Resources 


Fuel/Resource  Y/Resource  Z  -  Not  Used 
Triggers  -  Detect  Friend 
End  of  Run  MOE  -  Default  Settings 

Red  Agent 

Other  Properties  -  Default  Settings 

Terrain  Preference  -  Default  Settings 

Weapon  Possession  -  Basic 

Engagement  Desire  -  Default  Settings 

Sensor  Possession  -  Universal 

Comms  Possession  -  Not  Used 

Side  Property  -  Red 

Attributes  -  Not  Used 

Resources  -  Not  Used 

Triggers  -  Not  Used 

End  of  Run  MOE  -  Default  Settings 

Shore  Agent 

Other  Properties  -  Default  Settings 
Terrain  Preference  -  Default  Settings 
Weapon  Possession  -  Not  Used 
Engagement  Desire  -  Default  Settings 
Sensor  Possession  -  Default  Settings 
Comms  Possession  -  Default  Settings 
Side  Property  -  Blue 
Attributes  -  Not  Used 
Resources 

Fuel/Resource  Y/Resource  Z  -  Not  Used 
Triggers  -  Detect  Friend 
End  of  Run  MOE  -  Default  Settings 


Figure  20.  Pythagoras  Model  Parameters. 


Ill 


Jb.  Differences  in  Pythagoras 

The  differences  between  Pythagoras  and  MANA  were 
not  as  dramatic  as  the  differences  between  JCATS  and 
Pythagoras.  The  first  difference  was  the  implementation  of 
fuzzy  logic  or  soft  decision  rules  for  agent  actions.  The 
concept  of  applied  mathematics  to  decision  making  was  used 
to  better  model  the  human  factors  as  discussed  above.  The 
second  difference  was  the  representation  of  the  battle  space 
in  Pythagoras,  which  lacked  unit  icons.  This  did  not  affect 
the  simulation  capabilities. 

The  third  difference  was  use  of  the  DOS  command 
line  to  run  the  simulation.  This  took  away  the  usability  of 
the  simulation  and  forced  uncommon  program  language  on 
novice  users.  The  fourth  difference  was  outputted  data 
format.  Where  MANA  produces  Transmission  Control  Protocol 
(TCP)  and  User  Datagram  Protocol  (UDP)  packets,  Pythagoras 
used  Extensible  Markup  Language  to  output  data  and  scenario 
information.  These  methods  both  have  their  place  in  the  M&S 
technology  world  and  were  accessible. 

The  fifth  difference  was  the  addition  of  resources 
that  enabled  measurements  of  multiple  elements  in  the  model. 
The  fuel  representation  in  MANA  limited  it  to  a  single 
measurement  where  Pythagoras  expanded  the  idea  of  MOPs  and 
MOEs.  The  sixth  difference  addressed  the  capability  of 
Pythagoras  to  change  entity  "sideness"  of  an  agent  if 
altered  in  the  simulation.  This  option  was  not  engineered 
into  MANA  and  provided  a  more  robust  ability  to  model 
scenarios  other  than  conventional  warfare  directly  that 
could  impact  SBE  Scenarios . 
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c. 


Expected  Results 


The  SBE  Scenario  modeled  in  Pythagoras  was  not 
iterated  for  analysis  purposes  due  to  the  amount  of  time 
needed  for  simulation  iterations.  It  was  also  determined 
from  single  run  iterations  that  the  results  obtained  were 
similar  to  those  of  MANA  and  that  multiple  simulation 
replications  were  not  required  for  evaluation  the  model. 
The  limited  number  of  simulations  conducted  showed  similar 
survivability  rates,  transit  times,  and  cargo  transfers  to 
those  obtained  in  MANA.  There  were  two  additional  results 
that  were  observed  in  Pythagoras  that  increased  its 
scalability.  The  first  was  Battle  Damage  Assessment  results 
that  were  recorded  for  simulation  runs.  The  second  was  the 
recorded  changes  to  agent  attributes. 

C.  NEXT -EVENT  BASED 

Next-event  or  discrete  event  based  models  are  based  on 
the  sequential  events  that  happen  within  the  simulation  vice 
a  given  time  interval.  Next-event  based  models  are 
notionally  represented  by  event  graphs  that  depict  the 
elements,  variables,  and  relationships  of  the  simulation. 
The  processing  power  of  a  next-event  simulation  is  in  the 
future  event  list  and  that  no  event  can  happen 
simultaneously  with  another.  This  makes  DES  more  accurate 
than  time-step  based  models.  All  models  used  have  these 
basic  elements  and  operate  on  these  principles  (Buss,  2002) . 

1.  Naval  Simulation  System 

NSS  was  developed  by  the  Operations  Analysis  and 
Simulation  Sciences  (OASiS)  Group  of  the  Metron 
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Incorporation  under  Space  and  Naval  Warfare  Systems  Command 
(SPAWAR)  direction  (PD-15)  .  NSS  is  a  model  that  utilizes  a 
classified  database  in  most  cases  and  is  property  of  the 
U.S.  Government.  NSS  has  had  limited  testing  for  W&A  due 
to  lack  of  funding,  however,  contractor  support  and  training 
is  available  upon  reguest.  NSS  is  an  object  orientated 
Monte  Carlo  M&S  tool  that  provides  up  to  theater  level 
scenario  application.  It  has  been  used  in  fleet  exercises 
as  well  as  war  gaming  to  develop  courses  of  actions  for 
naval  commands.  NSS  is  designed  to  be  use  at  the  staff 
level  (Metron,  2007) . 

NSS' s  capability  to  model  the  full  spectrum  of 
maritime,  joint,  and  combined  military  operations  made  it 
well  suited  for  the  SBE  Scenario.  Similar  to  MANA,  T- 
craft' s  track  was  used  to  model  the  sea  lanes  of 
communication.  There  were  two  assumptions  made  in  modeling 
the  SBE  Scenario  in  NSS:  (1)  Monte  Carlo  features  were 
sufficient  to  have  results  matched  to  AABM  that  enabled  for 
stochastic  processes.  Initial  simulation  iterations  of  the 
Advance  Scenario  revealed  stochastic  survivability  results. 
This  was  determined  to  fit  into  the  capability  hierarchy. 
(2)  Logistical  support  was  assumed  to  be  present.  NSS  had 
the  capability  of  initializing  logistical  support  to  units. 
The  scenarios  were  simulated  without  the  use  of  logistical 
functions.  Logistical  options  were  not  used  to  maintain 
consistency  among  models  used.  Figure  21  presents  the  Basic 
Scenario  map  viewed  in  the  input  editor. 
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Figure  21.  NSS  Map  Overview. 

Analysis  of  the  NSS  simulation  replications  were  not 
preformed  on  this  model.  There  were  multiple  runs  conducted 
on  the  Basic  and  Advanced  Scenario  for  evaluation  purposes 
due  to  time  restriction.  NSS  has  been  an  accredited  M&S 
tool  and  extensively  used  by  Commander  Pacific  Fleet, 
SPAWAR,  naval  air  commands  and  operation  offices.  Scenario 
analysis  in  NSS  was  determined  to  not  be  needed,  based  on 
its  accreditation. 

a.  Parameters 

The  NSS  model  was  created  through  the  use  of  five 
selection  tabs  in  the  input  editor.  The  five  tabs 
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controlled  forces,  C2  plans,  ops  plans,  mission  plans,  and 
track/region  editor.  The  unit  instances  were  retrieved  from 
the  NSS  database  their  actions  were  altered  in  accordance 
with  the  SBE  Scenario.  Unit  instance  settings  for  escort 
forces  and  T-craft  are  listed  in  Figures  58  through  61,  and 
hostile  forces  are  contained  in  Figures  62  through  66. 
Figures  67  through  68  list  blue  force  parameters  used  in  the 
Advanced  Scenario.  The  Basic  Scenario  was  modeled  with  same 
parameters  as  the  Advanced  Scenario  with  the  exception  of 
escort  and  hostile  forces,  where  red  forces  are  shown  in 
Figures  61  and  65  through  66.  There  were  controls  like 
communication  networks  and  warfare  commander  plans  that 
attempted  to  persuade  entity  actions.  The  default  settings 
were  retained  for  sensor,  signature,  and  weapons  for  unit 
instances . 

The  commander  warfare  plans  selection  tabs  are 
shown  in  Figures  69  and  70.  These  figures  grouped  the 
operational,  C2,  and  mission  settings  in  one  figure  to  show 
the  default  settings  for  all  controls.  Blue  and  red  force 
settings  were  identical  and  based  on  the  instance  generated 
from  the  NSS  database.  One  variation  from  default  settings 
was  the  all  unit  check  box  was  selected  in  the 
communications  tab  to  assist  in  scenario  speed.  The  time 
duration  of  the  SBE  Scenario  was  entered  as  9  hours  to 
facilitate  sufficient  time  for  T-craft  to  complete  a 
successful  mission.  The  Advanced  Scenario  incorporated 
hostile  air  forces  depicted  as  MIG  23s  and  SU-24s  and 
introduced  the  design  element  used  in  the  other  M&S  tools  of 
hostile  air  threats. 
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b.  Expected  Results 


NSS  was  determined  to  yield  two  of  the  three  MOPs 
based  on  limited  runs  performed.  The  MOE  selection  was 
limited  to  model  defined  parameters  that  were  not  flexible 
for  SBE  Scenarios.  Transit  time  of  T-craft  was  presented  in 
the  application  of  MOE  to  the  scenario;  survivability  was 
selected  as  a  second  MOP  to  be  recorded.  The  third  MOP  was 
not  measurable  in  NSS  due  to  the  lack  of  functionality  in 
entities  to  carry  and  transfer  cargo.  The  MOP  did  not  fit 
into  the  logistical  support  functionality.  A  functionality 
that  was  added  to  MOP  selection  that  was  not  initially 
considered  was  the  use  of  confidence  intervals.  This  was 
integrated  into  the  accuracy  functionality  under 
replication . 

2 .  Simkit 

Simkit  was  created  at  the  NPS  in  1996  by  professor 
Arnold  Buss  and  graduate  student  Kirk  Stork  to  represent 
sensor  oriented  objects  in  a  model  and  simulation 
environment  to  better  model  processes  that  provided 
alternatives  to  expense  processes.  The  concept  of  discrete 
event  simulation  (DES)  was  centered  on  modeled  abstract 
objects  in  a  computer  program  that  used  event  graph  logic. 
Simkit  was  originally  implemented  in  the  Java  computer 
language  by  Sun  Microsystems.  DES  can  widely  be  applied  to 
other  computer  languages,  but  the  Basic  and  Advanced 
Scenario  were  both  written  in  Java  based  on  the  reusability 
of  predefined  object  classes  in  the  Simkit  library  at  the 
NPS  (Stork,  1996) .  The  user  interface  was  at  the 
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Application  Programmer  Interface  (API)  level  that  required 
extensive  modeling  and  use  of  the  libraries  (Buss,  2002)  . 

The  advantage  of  modeling  abstract  objects  in  DES  was 
the  use  of  the  Listener  Event  Graph  Objects  (LEGO)  component 
framework  that  enabled  T-craft  to  be  specifically  modeled 
and  not  the  scenario  processes.  Cargo  transfer  and 
logistical  processes  were  modeled  in  extensive  detail  to 
account  for  all  aspects  of  the  SBE  Scenario.  This  allowed 
for  powerful  modeling  of  the  SBE  Scenario  processes,  for 
example,  all  three  MOPs  were  implemented  and  measured  with 
more  accuracy  than  time-step  based  models  (Buss,  2002)  . 
Simkit  has  a  wide  variety  of  uses  and  the  NPS  studies  that 
have  used  Simkit  included  port  usage,  sonar  process,  and 
security  issue  models  to  show  the  versatility  of  the  M&S 
tool . 

Deterministic  and  stochastic  models  depend  on  input 
parameters.  The  use  of  an  API  allowed  for  the  use  of  random 
processes  and  slightly  stochastic  models  to  be  generated  for 
the  SBE  Scenarios.  The  reason  for  this  was  the  pseudo 
random  nature  of  the  variant  generation  factory  within 
Simkit.  The  advantage  of  using  a  Java  based  program  was 
that  a  robust  statistical  analysis  capability  was  available. 
The  data  analysis  tools  embedded  in  Simkit  produced  user 
defined  analyzed  results  from  multiple  simulation  runs  at 
the  end  of  run  time. 

Figures  22  and  23  are  the  simple  flow  diagrams  that 
represent  the  Basic  and  Advanced  Scenario  implemented  with 
the  Simkit  API.  The  detailed  event  graphs  for  the  Simkit 
model  are  shown  in  Figures  71  through  77.  The  detailed 
model  illustrates  the  conditions  and  parameters  used  to 
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model  the  SBE  Scenario.  The  model  represented  the 
interaction  stations  as  states  that  indicated  to  the  T-craft 
platform  object  what  action  to  perform.  MOPs  were  state 
variables  that  were  linked  to  the  platform  objects  and  used 
property  change  functions  to  account  for  the  change  over  a 
single  iteration  and  not  over  the  total  number  of 
replications . 


Figure  22.  Event  Graph  for  Basic  Scenario. 

There  were  two  assumptions  used  in  the  T-craft  Mover 
Manager.  The  first  assumption  was  that  T-craft  proceed  back 
to  debarkation  point  and  not  repaired  once  the  mission  was 
successful.  The  reality  was  that  T-craft  could  stop  for 
repairs  at  the  SBO,  but  was  not  modeled  to  in  Simkit.  Time 
limitations  did  not  allow  for  debugging  and  revision  of  the 
code.  The  second  assumption  was  that  T-craft  departed  the 
SBO  with  cargo  greater  than  or  equal  to  the  minimum  load 
requirement  of  the  scenarios.  This  was  defined  in  the 
parameters  section  and  required  for  T-craft  to  transit  to 
the  shore  landing  site  when  cargo  was  needed  for  the  mission 
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objective.  Real-world  application  of  T-craft  could  allow 
transit  to  the  shore  with  any  amount  of  cargo. 

In  addition  to  the  above  assumptions  there  was  a  repair 
facility  implemented  in  the  Advanced  Scenario.  The  repair 
facility  was  located  in  the  SBO  state  in  an  attempt  to  model 
the  SBO  capability  for  repairs  of  T-craft  during  mission 
execution.  An  Arena  model  created  by  Mary  McDonald,  a 
research  associate  of  the  SEED  center  at  the  NPS,  was  the 
basis  for  evaluation  of  the  Arena  M&S  tool  used  as  the  sixth 
model  for  evaluation.  Other  work  included  a  SBE  model  that 
was  created  by  Major  Sebastian  Scheibe  from  the  Germany  Army 
at  the  NPS.  The  purpose  of  the  Scheibe  model  was  to 
determine  critical  capabilities  of  T-craft  listed  in  BAA 
(05-020) .  One  major  MOP  that  Major  Scheibe  concentrated  on 
was  survivability  when  a  repair  factor  was  introduced  to  an 
Arena  model  (Scheibe,  2010)  .  This  was  the  basis  for  the 
added  repair  station  in  the  Advanced  Scenario.  Figure  23 
shows  the  Advanced  Scenario  modeled  in  Simkit. 
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Figure  23.  Event  Graph  for  Advanced  Scenario. 


a.  Parameters 

There  were  two  types  of  variables  used  in  Simkit 
that  were  used  as  measurements  in  the  scenario  models.  The 
first  was  a  set  of  State  variables  that  were  defined  as 
variables  that  change  at  least  once  during  simulation. 
Table  13  lists  the  state  variables  used  in  the  Basic  and 
Advanced  Scenario.  The  variables  represented  states  and 
input  parameters . 
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State  Variables 

Label 

Definition 

Value 

c 

Cargo  carried  in  T-craft  (Tons) 

<  750 

D 

Damage  taken  by  T-craft 

(0  -  1) 

s 

State  Variable  (Debarkation,  SBO,  Shore) 

2D  Point 

X 

Survivability  rate  of  T-craft 

(0  I  1) 

sc 

Shore  landing  site  Cargo  received  (Tons) 

ST 

M 

Mission  status  Flag 

(0  I  1) 

tx 

Delay  Time  for  transit  time  of  T-craft 

Triangle  (0,  90, 
180) 

tL 

Delay  Time  for  loading  time  of  T-craft 

Exp  (X) 

tR 

Delay  Time  for  repair  time  of  T-craft 

Exp  (X) 

tu 

Delay  Time  for  unloading  time  of  T-craft 

Exp  (X) 

to 

Delay  Time  for  detection  time  of  hostile  sensor 

Triangle  (0,  10, 
20) 

tM 

Delay  Time  for  movement  time  of  unit 

Un  (100,  1) . 

tE 

Delay  Time  for  End  of  Service 

waitDelay  =  1.0 

tv 

Delay  Time  for  Entering  Range 

N  (10,  1) 

tG 

Delay  Time  for  Exit  Range 

N  (10,  1) 

UC 

Random  amount  of  cargo  loaded  on  to  T-craft 

U  ~  Un (0, 750) 

Table  13.  Simkit  State  Variables. 


The  second  type  of  variable  is  the  set  of 

Parameter  variables.  The  Parameters  variables  represented 

constant  values  in  scenario  used  to  determine  damage  and 

cargo  thresholds.  Table  14  lists  the  Parameters  used  in  the 

Basic  and  Advanced  Scenario.  The  damage  threshold  (DT)  was 

used  to  determine  when  entities  reached  critical  points  of 

sustained  damage.  The  repair  threshold  (RT)  indicated  the 

need  for  repairs  based  on  sustained  damaged.  Along  with 

threshold  settings,  there  were  gueues  size  parameters,  which 

defined  t-craft  force  levels,  repair  facilities,  and  shore 

landing  sites.  Shore  landing  site  (SL) ,  repair  facility 

(R)  ,  and  loading  stations  (L)  were  set  to  one.  The  last 
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parameter  used  was  a  two  dimensional  point  vector  parameter 
that  represented  a  geo-graphical  location  in  the  environment 
that  was  used  for  movement  and  modeled  physics. 


Parameters 

Label 

Definition 

Value 

MinLD 

Minimum  Load  for  T-craft  (Tons) 

min  =  300 

MaxLD 

Maximum  Load  for  T-craft  (Tons) 

max  <=  750 

DT 

Damage  threshold 

dt  =  0.8 

RT 

Repair  Threshold 

rt  =  0.3 

CT 

Cargo  Threshold 

ct  =  750 

SL 

Number  of  shore  landing  sites 

1 

R 

Number  of  Repair  Facilities 

1 

L 

Number  of  Loading  Facilities 

1 

UL 

Number  of  Unloading  Facilities 

1 

ST 

Shore  landing  site  cargo  threshold 

2000 

G 

Debarkation  Point 

2D  Point 

H 

SBO  Point 

2D  Point 

I 

Shore  landing  site  Point 

2D  Point 

Table  14.  Simkit  Parameters. 


The  detailed  Simkit  model  depicted  the  algorithm 
used  for  logic  problem  solving  that  made  the  T-craft  model 
object  change  states  and  transfer  cargo  to  the  shore  landing 
site.  This  was  fundamentally  different  that  AABM  that  used 
waypoints  to  direct  motion  and  actions  of  agents.  The  DES 
relied  heavily  on  user  defined  methods  to  guide  the  course 
of  actions  for  the  scenario.  The  methods  used  to  create 
randomness  in  the  simulation  were  distributions  curves. 

There  are  three  basic  distributions  that  were  used 
in  Simkit.  The  first  distribution  was  a  Uniform  (Un)  that 
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provided  random  motion  of  hostile  and  escorts  forces  in  the 


defined  battle  space  of  the  SeaBase.  Time-step  model'’ s 
random  movement  was  arbitrarily  to  an  image,  where  DES 
required  correct  physical  interactions  and  placement. 
Uniform  distributions  were  used  to  model  the  randomness  of  a 
ship's  movement  in  the  operation  area  (tM)  and  for  cargo 
load  rates  (uc)  . 

The  second  was  a  Triangle  distribution  that  was 
based  on  the  knowledge  of  limits  to  the  distribution  but  no 
evidence  recorded  to  validate.  Given  the  transit  time 
results  from  the  MANA  simulation,  a  rough  gage  of  the  time 


needed  to 

transit 

the  distance 

in 

the 

scenario  was 

taken 

from  Table 

13  to 

define  transit 

(tx 

)  ,  enter  (tv)  ,  and 

exit 

range  (tG) 

times  . 

The  last 

was 

an 

Exponential 

(Exp) 

distribution  that 

described  rates 

of 

a  process. 

The 

distribution  selected  for  loading,  unloading,  and  repair 
delays  can  be  based  on  historical  logistic  mean  times  of 
completion.  Generic  place  holders  were  used  for  the  Simkit 
model . 


Jb.  Design  of  Experiments 

The  iteration  of  the  Simkit  model  over  a  design 
space  was  based  on  the  need  to  test  the  model  prior  to 
extensive  simulation  runs  in  the  Simkit  environment  and  to 
determine  the  number  of  runs  needed  that  would  produce 
sufficient  trials  for  statistical  results.  Event  graph 
models  allowed  for  the  user  to  hand  simulate  the  model. 
This  function  was  used  to  test  the  range  of  the  model  prior 
to  replication.  It  also  allowed  for  debugging  of  the 
algorithms  prior  to  code  generation.  The  idea  behind  the 


hand  simulation  was  to  test  the  model  for  all  possible 
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states  and  situation  T-craft  transitioned  to.  Table  15 
shows  the  design  of  experiments  for  the  hand  simulation 
method.  The  two  factors  that  were  varied  are  cargo  load 
outs  and  starting  location.  This  also  showed  that  three 
starting  states  were  not  possible  in  a  SBE  Scenario  based  on 
earlier  assumptions.  For  example,  the  T-craft  could  not 
start  from  the  SBO  without  cargo  loaded;  otherwise,  the 
mission  would  be  satisfied.  The  other  starting  states  that 
were  not  possible  were  departing  the  shore  landing  site  with 
cargo.  The  T-craft  was  designed  to  unload  all  cargo  at  the 
shore  landings  site.  An  important  consideration  in  the 
verification  of  the  model'’ s  predicted  outcome  was  the  use  of 
non  random  delay  times.  Each  hand  simulation  had  similar 
even  delay  times  that  enabled  low  computational  stress  in 
carrying  out  the  calculations. 
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Hand 

Simulation  Design  of 

Experiments 

Design 

Point 

Starting  State 

Initial  Cargo  Load 

1 

Debarkation 

0 

2 

Debarkation 

300 

3 

Debarkation 

750 

4 

SBO 

0 

5 

SBO 

300 

6 

SBO 

750 

7 

SHO 

0 

8 

SHO 

300 

9 

SHO 

750 

Note:  Not  a  possible  starting  state  for  a 

SBE  Scenario. 

Table  15.  Hand  Simulation  Design  of  Experiments. 


The  second  design  question  was  determining  the 
number  of  simulation  runs  required  to  obtain  statistical 
significant  results.  The  number  of  simulation  iterations 
was  set  at  10,000  replications.  Given  the  starting  states 


in  Table  15,  10,000  replications  were  conducted  at  each 

starting  point  to  collect  data  on  the  three  MOPs . 


c.  Expected  Results 

The  expected  results  of  the  Simkit  model  were 
originally  assumed  to  match  the  characteristics  of  the 
distributions  chosen  for  the  inputted  values.  The  triangle 
distribution  of  the  transit  and  detection  delays  coupled  to 
the  exponential  rates  of  the  loading  states  produced  a  mean 
that  was  translatable  to  real-world  processes.  This 
research  was  not  directed  at  validating  the  results  of 
Simkit  but  merely  to  evaluate  obtained  results.  It  did  seem 
to  be  highly  likely  that  the  model,  developed  with  actual 
data  to  model  the  SBE  Scenario,  increased  its  usability. 

d.  Data  Analysis 

The  results  of  the  hand  simulation  are  listed  in 
Table  16.  The  results  did  show  the  full  range  of  expected 
outcomes  needed  to  model  the  Advanced  Scenario.  The 
survivability  rate  of  the  T-craft  indicated  that  further 
simulation  in  Simkit  should  provide  sufficient  results  for 
analysis.  The  transit  times  and  cargo  delivered  results  of 
the  hand  simulation  are  also  comparable  to  those  of  MANA. 
The  hand  simulation  calculations  are  shown  in  Figures  78 
through  83. 
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Hand  Simulation  Results 

Initial  State 

Initial  Cargo 

Cargo 

Time 

Survivability 

Debarkati 

on 

0 

1060 

82 

X  =  0 

Debarkati 

on 

300 

2260 

181 

X  =  1 

Debarkati 

on 

750 

360 

62 

X  =  0 

SBO 

0 

SBO 

300 

2030 

122 

X  =  0 

SBO 

750 

2480 

126 

X  =  1 

SHO 

0 

1060 

92 

X  =  0 

SHO 

300 

SHO 

750 

Table  16.  Hand  Simulation  Results. 


The  results  from  the  Simkit  simulation  of  the  SBE 
Scenario  are  listed  in  Table  17  through  19.  The  Basic 
Scenario  illustrated  the  capability  of  statistical  analysis 
of  Simkit  and  measured  the  processes  to  enable  optimization. 
The  Simkit  model  in  Appendix  C  represented  the  Advanced 
Scenario  and  was  configured  for  measuring  MOPs .  The  results 
showed  that  Simkit  was  affected  by  distributions  in  the 
modeling  of  T-craft  in  a  pseudo  stochastic  environment. 
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Simkit  Simulation  Results 

Replications  {100} 

Trips  (1) 

Measures  of  Performance 

Distribution 

Parameters 

Shore  Cargo 
Transferred  (LT) 

Survivabillity 
Rate  (%) 

Transit 

Times  (sec) 

Uniform  [0,  750] 

450.79  ±  266.95 

54.0 

5.38  ±  2.92 

Normal  [525,  200] 

440.11  +  283.91 

44.0 

5.76  ±  5.25 

Exponential  [300] 

457.54  +  281.95 

52.0 

5.93  ±  4.31 

Replications 

Trips 

{1000} 

(1) 

Measures  of  Performance 

Distribution 

Parameters 

Shore  Cargo 
Transferred  (LT) 

Survivabillity 

Rate 

Transit 

Times  (sec) 

Uniform 

[0, 

750] 

436.29  ±  266.25 

48.2 

5.83  ±  5.02 

Normal 

[525, 

.  200] 

440.09  ±  286.60 

49.6 

5.74  ±  4.68 

Exponential 

[300] 

433.43  ±  293.63 

49.2 

5.32  +  3.53 

Replications 

Trips 

{10000} 

(1) 

Measures  of  Performance 

Distribution 

Parameters 

Shore  Cargo 
Transferred  (LT) 

Survivabillity 

Rate 

Transit 

Times  (sec) 

Uniform 

[0, 

750] 

435.31  +  271.69 

49.3 

5.51  ±  4.19 

Normal 

[525, 

.  200] 

441.33  ±  290.69 

49.3 

5.50  <  4.03 

Exponential 

[300] 

441.33  ±  287.81 

49.6 

5.52  ±  4.30 

Table  17.  Simkit  Results  (One  Trip  to  Shore) . 


Simkit  Simulation  Results 

Replications  {100} 

Trips  (2) 

Measures  of  Performance 

Distribution 

Parameters 

Shore  Cargo 
Transferred  (LT) 

Survivabillity 
Rate  (%) 

Transit 

Times  (sec) 

Uniform  [0,  750] 

637.42  ±  475.05 

24.0 

6.10  ±  3.60 

Normal  [525,  200] 

665.20  ±  486.42 

30.0 

6.50  ±  4.63 

Exponential  [300] 

529.94  ±  484.77 

36.0 

7.65  ±  6.31 

Replications 

Trips 

{1000} 

(2) 

Measures  of  Performance 

Distribution 

Parameters 

Shore  Cargo 
Transferred  (LT) 

Survivabillity 
Rate  (%) 

Transit 

Times  (sec) 

Uniform 

[0, 

750] 

702.31  ±  456.86 

30.9 

6.79  +  4.53 

Normal 

[525, 

.  200] 

703.11  ±  483.12 

30.4 

6.84  +  4.80 

Exponential 

[300] 

452.62  ±  405.61 

30.5 

6.72  +  4.35 

Replications 

Trips 

{10000} 

(2) 

Measures  of  Performance 

Distribution 

Parameters 

Shore  Cargo 
Transferred  (LT) 

Survivabillity 
Rate  (%) 

Transit 

Times  (sec) 

Uniform 

[0, 

750] 

702.54  ±  462.63 

31.2 

6.85  ±  4.74 

Normal 

[525, 

.  200] 

703.11  ±  483.12 

30.4 

6.84  ±  4.80 

Exponential 

[300] 

460.46  ±  405.61 

30.9 

6.73  ±  4.66 

Table  18.  Simkit  Results  (Two  Trips  to  Shore) . 
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1  Simkit  Simulation  Results  j 

Replications  {100} 

Trips  (3) 

Measures  of  Performance 

Distribution 

Parameters 

Shore  Cargo 
Transferred  (LT) 

Survivabillity 
Rate  (%) 

Transit 

Times  (sec) 

Uniform  [0,  750] 

676.28  ±  537.54 

14.0 

-j 

K) 

00 

1+ 

00 

Normal  [525,  200] 

706.21  +  551.46 

17.0 

7.30  ±  4.67 

Exponential  [300] 

549.19  ±  489.62 

19.0 

7.44  +  4.67 

Replications 

Trips 

{1000} 

(3) 

Measures  of  Performance 

Distribution 

Parameters 

Shore  Cargo 
Transferred  (LT) 

Survivabillity 
Rate  (%) 

Transit 

Times  (sec) 

Uniform 

[0, 

750] 

781.62  ±  498.04 

15.4 

7.82  ±  5.25 

Normal 

[525, 

.  200] 

776.14  ±  527.92 

14.3 

<x> 

+1 

r- 

Exponential 

[300] 

521.23  ±  480.42 

19.2 

7.42  ±  4.95  1 

Replications 

Trips 

{10000} 

(3) 

Measures  of  Performance 

Distribution 

Parameters 

Shore  Cargo 
Transferred  (LT) 

Survivabillity 
Rate  (%) 

Transit 

Times  (sec) 

Uniform 

[0, 

750] 

744.37  +  518.41 

14.7 

7.44  ±  5.24 

Normal 

[525, 

.  200] 

752.62  ±  530.71 

14.4 

7.34  +  5.06 

Exponential 

[300] 

540.61  ±  484.60 

17.6 

7.44  ±  5.08 

Table  19.  Simkit  Results  (Three  Trips  to  Shore) . 
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Simkit  Raw  Data  (Exert) 

Number  of  Replications  = 
Number  of  Trips  =  1 
Uniform  Distribution 
Parameters  are  [0,750] 

100 

Shore  Cargo 

Survivability 

Time 

469.28 

1 

5.40 

0.00 

0 

1.26 

738.82 

1 

7.17 

381.89 

0 

5.66 

391.23 

1 

6.12 

441 . 07 

1 

9.42 

405 . 54 

0 

6.77 

740 . 65 

1 

6.88 

836.81 

1 

3.90 

511.24 

1 

9.07 

320.83 

1 

5.25 

621.89 

1 

5.08 

456.55 

1 

6.09 

561 . 93 

0 

19.78 

665.75 

1 

7.90 

0.00 

0 

2.56 

740 . 77 

1 

7 .10 

575.28 

0 

8.81 

669.77 

0 

6.46 

970 . 78 

1 

7.30 

0.00 

0 

0.88 

703.29 

1 

6.37 

505.16 

1 

5.76 

713 . 77 

0 

8.25 

346 . 44 

1 

6.56 

605.55 

0 

5.37 

566.33 

0 

4 .19 

835.02 

0 

4.03 

742 . 18 

1 

4.41 

0.00 

0 

0.69 

0.00 

0 

2.07 

640.07 

1 

3.68 

885.71 

1 

4.85 

352.59 

1 

7.98 

675.01 

1 

6.32 

0.00 

0 

1.56 

0.00 

0 

2.16 

359.51 

1 

7.30 

0.00 

0 

0.74 

586.05 

1 

8.72 

Table  20.  Simkit  Data  Collection  Excerpt. 
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Simkit  results  behaved  similarly  to  those  of  MANA, 
in  that  when  more  trips  to  the  shore  were  implemented,  cargo 
transfer  increased  at  the  shore  landing  site.  The  confidence 
interval  magnitudes  from  the  Simkit  simulation  were  larger, 
giving  a  wider  range  for  the  actual  value  to  be  in.  This 
meant  that  the  cargo  transfer  rates  modeled  within  the 
simulations  were  subjective  to  the  developer  of  the 
simulation  and  the  modeler  of  T-craft  and  yielded  results 
similar  but  not  realistic  to  actual  cargo  transfer  rates. 

3 .  Arena  Simulation 

The  Rockwell  Automation  Arena  software  M&S  tool  is 
primarily  designed  for  business  process  applications. 
Arena' s  main  versatility  is  based  on  converting  flowchart 
process  in  a  model  that  can  be  simulated  for  analysis. 
Arena  was  developed  by  the  Rockwell  Automation  Technologies 
Incorporated  in  2007.  The  Arena  M&S  tool  is  recommended  for 
uses  in  (1)  documenting,  visualizing,  and  demonstrating 
processes  with  animation,  (2)  predicting  system  performance, 
(3)  identifying  system  choke  points,  and  (4)  planning 
requirements.  (RA,  2007)  Arena  is  designed  for  use  in  the 
business  environment  and  is  less  capable  than  Simkit  for 
military  operations. 

As  mentioned  earlier,  the  evaluation  of  the  Arena  M&S 

tool  was  based  on  a  model  created  by  Mary  McDonald,  a 

research  associate  of  the  NPS .  The  McDonald  model 

implemented  the  second  phase  of  the  SBE  Scenario  where  the 

scenario  starts  at  the  SBO  and  SBEs  transit  to  and  from  the 

shore  landings  site  transferring  cargo.  It  was  a  basic 

model  that  focused  on  the  cargo  measurement  and  not 

survivability.  An  extrapolation  in  areas  relating  to  the 
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MOPs  of  the  McDonald  model  was  the  focus  of  this  research. 
As  with  Pythagoras,  simple  testing  was  conducted  with  Arena 
to  determine  the  presence  of  functionalities  in  the  Arena 
model  and  evaluate  the  capabilities  of  the  M&S  tool.  The 
Arena  model  was  iterated  over  multiple  runs  to  determine  the 
transfer  patterns  and  survivability  rates  similar  to  other 
M&S  tools  in  this  study. 

a.  Parameters 

The  McDonald  model  imported  values  from  a  database 
that  runs  the  model.  The  database  consisted  of  14 
independent  variables  that  are  listed  below.  The  model  also 
created  multiple  T-craft  objects  for  transferring  cargo. 
The  time  delay  was  a  random  exponential  distribution  with 
the  process  containing  51  T-craft  entities.  T-craft 
entities  conducted  transfer  of  cargo  in  batches  to  the  shore 
landing  site  and  were  then  disposed  of  once  a  threshold  of 
cargo  was  reached.  The  McDonald  model  replicated  the 
process  512  times.  The  McDonald  model  did  not  implement  the 
return  transit  to  the  debarkation  point,  but  did  input 
attack  probabilities  into  the  transit  processes.  Figure  24 
shows  the  McDonald  model  in  Arena  and  illustrates  the 
generation  process  of  the  entities  from  the  database  with  a 
separate  block  for  reading  input  from  a  designated  file. 
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Figure  24.  McDonald  Arena  Model  Overview. 


The  following  is  a  listing  of  the  variables  that 
were  parameter  settings  in  the  McDonald  model .  The  database 
was  divided  into  14  different  independent  variables  that 
were  used  to  then  calculate  12  dependent  variables.  The 
dependent  variables  were  calculated  outside  the  model  and 
then  used  as  input  parameters  for  model  simulation. 

•  Cargo  Payload  Weight  (Long  Tons) 

•  Cargo  Deck  Size  (Square  Feet) 

•  Speed  in  Knots 

•  Loading  Time  in  hours 

•  Unloading  Time  in  hours 

•  Number  of  T-craft 

•  Number  of  Sea  Spots  for  Loading 

•  Refueling  during  Loading  (Boolean  Value) 

•  Refueling  Rates  (Tons/hour) 

•  Cargo  Capacities  (Long  Tons) 

•  Fuel  Consumption  while  Loaded  (Long  Tons) 

•  Fuel  Consumption  while  Unloaded  (Long  Tons) 
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Batch  Size 


•  Number  of  Hits  until  Repair  needed 

Jb.  Differences  in  Arena 

The  most  notable  difference  in  Arena  from  Simkit 
was  the  GUI  that  was  available  in  Arena.  However,  the  GUI 
presence  did  not  overcome  certain  short  comings  that  an 
object  orientated  M&S  tool  supports.  Arena  was  able  to 
display  models  graphically,  but  lacked  the  computational 
power.  The  lack  of  versatile  variables  and  extensive  random 
numbers  separated  Arena  from  the  Simkit  that  has  robust 
methods  for  stochastic  processes.  The  results  from  an  Arena 
model  were  simple  and  not  as  robust  as  the  statistical 
calculation  in  the  Simkit  API .  The  Arena  GUI  was  not  open 
sourced  and  reduced  user  capability  to  model  complex 
interactions  with  logic  programming.  These  factors,  coupled 
with  limited  combat  modeling  capabilities  made  Arena 
distinctively  different. 

Arena  and  Simkit  shared  one  similarity.  The 
capability  of  waiting  queues  to  be  used  for  measuring 
logistics  provided  information  in  analysis  on  force  factors 
and  composition.  Arena  was  specifically  designed  for 
business-like  applications  to  optimize  processes  and 
determine  the  best  combination  of  factors.  Waiting  queues 
were  the  basis  for  selecting  both  Simkit  and  Arena  M&S  tools 
in  this  research. 
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c.  Expected  Results 

The  SBE  Scenario  modeled  in  the  McDonald  model  was 
not  iterated  for  analysis  purposes  in  this  study.  Instead, 
the  McDonald  model  was  used  as  a  comparison  mechanism  to 
evaluate  Arena's  simulation  capabilities.  It  was  apparent 
from  initial  simulation  runs  that  the  primary  results 
obtained  from  provided  databases  were  comparable  with  Simkit 
results.  The  determination  was  made  that  extensive 
simulation  of  the  McDonald  model,  like  that  of  MANA,  would 
not  be  necessary  due  to  time  restriction  and  the  clear 
presence  of  M&S  capabilities.  Limited  simulations 
iterations  conducted  by  Mary  McDonald  did  show  similar 
survivability  rates,  transit  times,  and  cargo  transfers 
compared  to  Simkit,  which  indicated  the  model  was  a  viable 
SBE  Scenario.  Selection  of  MOPs  were  also  similar  to  those 
of  Simkit,  therefore,  high  replications  of  Arena  was  not 
needed  for  evaluation  purposes. 

M&S  tools  used  in  this  study  were  selected  base  on 
capabilities  to  model  a  SBE  and  availability  at  NPS .  The 
two  types  of  models  kept  within  the  constructive  realm  of 
M&S.  Each  M&S  tool  possessed  capabilities  and  limitations 
that  made  them  differently  suited  for  modeling  a  naval 
problem,  but  still  usable  to  apply  to  the  SBE  Scenario 
broadly  for  measuring  performance  characteristics.  The 
results  collected  in  this  chapter  were  too  used  to 
illustrate  obtainable  results  and  that  each  M&S  tool 
evaluated  by  subjectively  observed  functionalities  within 
the  capability  Hierarchy. 
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Figure  25. 
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Figure  26. 


T-craft  Personal  Settings. 
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Figure  27 . 


T-craft  Ranges 


Settings . 


Figure  2  8 . 


T-craft  Sensors 


Settings . 
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Figure  29. 


T-craft  Algorithm 


Settings . 


Figure  30. 


Escort  Personal 


Settings . 
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Figure  31 . 


Escort  Ranges 


Settings . 


Figure  32  . 


Escort  Sensors 


Settings . 
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Figure  33. 


Escort  Weapons 


Settings . 


Figure  34 . 


Hostile  Personal  Settings. 
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Figure  35. 


Hostile  Ranges 


Settings . 


Figure  36. 


Hostile  Sensors 


Settings . 
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Figure  37. 


Hostile  Weapons 


Settings . 


Figure  38. 


Hostile  Algorithm 


Settings . 
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Figure  39. 


Hostile  Air  Personal  Settings. 


Figure  40. 


Hostile  Air 


Ranges 


Settings . 
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Figure  4 1 . 


Hostile  Air 


Sensors 


Settings . 


Figure  42 . 


Hostile  Air 


Weapons 


Settings . 
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Figure  43.  Hostile  Air  Algorithm  Settings. 


□  Pythagoras:  CnmesrslPalhegofuousFtfesPythSOJwCargoXtor  .xml 


Figure  44 . 


Blue  Agent  Position  Property. 
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□  Pythagoras:  CnThoslsPathegoruousFHes'Pyth50JwCaigoXter.xml 


f~l  Pythagoras:  CrJhesisPathegoruousFilesPylhSOJwCargoXler.xml 

Overview  Terrain  Weapon  Sidedness  Sensor  Comms  Agent  Attribute  Clianger  Alternate  Behavior  MOE 

Agent  List 

Mew 

Blue 

Red 

Shore 

Delete 

Name:  b  Last  Modified: 


Figure  46. 


Blue  Agent  Speed  Property. 
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0  Pythagoras:  C:\Thesis\PathegoruousFileslPythSOJwCargoXfer.xml 


Name:  [Blue 


Description: 


Engagement  Desire  |  Sensor  Possession  |  Comm  Possession  |  Side  Property  [  Attributes  f  Resources 

Triggers  j  EndofRunMOEs 

Position  Property  \  Other  Properties  |  Speed  Property  [  Movement  Desire 

Terrain  Preference  Weapon  Possession 

Movement  Method:  |  Highest  Desire  1  ▼  | 

Title 

%/Count/Force  .. 

%/Counf/Force 

Desire 

Desire  Tolerance 

Distance 

Distance  Tolera... 

Toward  The  Leader  If  Farther  Than 

0.0 

0.0 

0.0 

0.0 

Away  From  The  Leader  If  Closer  Than 

0.0 

0.0 

0.0 

0.0 

T oward  Closest  Unit  Member  If  Farther  Than 

0.0 

0.0 

0.0 

0.0 

Away  From  Closest  Unit  Member  If  Closer  T 

0.0 

0.0 

0.0 

0.0 

Toward  Furthest  Unit  Member  If  Farther  Than 

0.0 

0.0 

0.0 

0.0 

Toward  Closest  Friend  If  Farther  Than 

0.0 

0.0 

0.0 

0.0 

Away  From  Closest  Friend  If  Closer  Than 

0.0 

0.0 

0.0 

0.0 

Toward  Furthest  Friend  If  Farther  Than 

0.0 

0.0 

0.0 

0.0 

Toward  Injured  Friend  (Fraction  Health) 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

Toward  Needing  Fuel 

0.0 

0.0 

0.0 

0.0 

Toward  Needing  ResourceX 

50.0 

0.0 

100.0 

0.0 

Toward  Needing  ResourceY 

0.0 

0.0 

0.0 

0.0 

Toward  Needing  ResourceZ 

0.0 

0.0 

0.0 

0.0 

Toward  Giving  Fuel 

0.0 

0.0 

0.0 

0.0 

Toward  Giving  ResourceX 

50.0 

0.0 

50.0 

0.0 

Toward  Giving  ResourceY 

0.0 

0.0 

0.0 

0.0 

Toward  Giving  ResourceZ 

0.0 

0.0 

0.0 

0.0 

Toward  Nearest  Enemy  If  Farther  Than 

0.0 

0.0 

0.0 

0.0 

Away  From  Nearest  Enemy  If  Closer  Than 

0.0 

0.0 

150 

0.0 

T oward  Nearest  Enemy  If  Fewer  Than  Count 

0 

0 

0.0 

0.0 

0.0 

0.0 

Away  From  Nearest  Enemy  If  More  Than  Co.. 

1 

0 

0.0 

0.0 

15.0 

0.0 

Toward  Nearest  Enemy  if  Force  Ratio  More ... 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

Away  From  Nearest  Enemy  If  Force  Ratio  L . 

1.5 

0.0 

0.0 

0.0 

0.0 

0.0 

Toward  Next  Waypoint 

80.0 

0.0 

5.0 

0.0 

Toward  Final  Objective 

15.0 

0.0 

Maintain  Last  Course 

0.0 

0.0 

Select  Random  Direction 

0.0 

0.0 

Stay  in  place 

0.0 

0.0 

j  Overview^  Terrain  |  Weapon  !  Sidedness  J  Sensor  |  Comms  Agent  |  Attribute  Changer  ]  Alternate  Behavior  |  MOE 


Red 

Shore 


Figure  47 . 


Blue  Agent  Movement  Desire. 
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□  Pythagoras:  CiTheslsPathegoruousFies'PythSOJiivCargoXfef -xml 
Overview  |  Terrain  ]  Weapon  Sidedness  :  Sensor  Comms  Agent 


Sgwtiisl 

m. 


Attribute  Changer  '  Alternate  Behavior  |  MOE  | 


Description:  | 


Engagement  Oesire  Sensor  Possession  Comm  Possession  Side  Property  ’  Attributes  Resources  Triggers  EndotRunMOEs 
Position  Property  j  Other  Properties  Speed  Property  Movement  Oesire  Terrain  Preference 


Load  Balance 


Fuel  Resource  X  Resource  Y  Resource  Z 
Consumer  Into: 


Total  Resource  X  Capacity:  |7SO.O  ~ 


Receiving  Resource  X  Priorities 


Percentage  ot  Resource  X  Capacity 
Initial  Resource  X  Selling 

initial  Resource  X  Amount  98  S 

■  — 

0  10  20  30  40  50  60  70  80  90 100  0  10  20  30  40  50  60  70  80  90100 


Normal  Reorder  Setting 

Normal  Reorder  Point  0  S 

Q  - 


Emergency  Reorder  Setting 
Emergency  Reorder  Point  0  % 

9 .  — — ; 

0  10  20  30  40  50  60  70  80  90100 


Initial  Resource  XAmount  Tolerance:  0  S  Normal  Reorder  Tolerance:  11 S  Emergency  Reorder  Tolerance:  0\ 

Q  -  —  Q  - ■ 


Enemy:  [refuse 


0  10  20  30  40  50  60  70  80  90  100  0  10  20  30  40  50  60  70  80  90100 


0  10  20  3040  50  60  70  80  90100 


Resource  X  Consumption  Per  Time  Step: 


Resource  X  Giving  Distance:  fioo  o 

Percentage  ot  Resource  X  Cargo  Capacity 

Initial  cargo  Setting 

imiial  Cargo  Amount  100% 

Resource  X  Giving  Rate  (per  Time  Slept  |350  0 

Total  Cargo  Capacity:  I750  0 

Giving  Resource  X  Pnonties 

Friend:  1 

Neutral:  jl  ▼ 

Initial  Cargo  tolerance:  0  % 

Q— — 

Enemy:  refuse  » 

0  10  20  30  40  50  60  70  80  90100 

Figure  4  8 . 


Blue  Agent  Resource. 


□  Pythagoras:  C::ThesisPafhegotuousF4esPylhSOJwCargoXlerjunl 


Figure  49. 


Red  Agent 


Position 


Property . 
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G  Pytnagoras:  C;  Thesis  Pailioflcxuousf lies PylhSOJwCargoXlef  xml 


Figure  50. 


Red  Agent  Speed  Property. 
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FI  Pythagoras:  C:  Thesis  PathegoruousFiles  PythSOJwCargoXter.xml 
Overview  Terrain  Weapon  Sidedness  Sensor  Comms  Agent  Attnbute  Changer  Alternate  Behavior  MOE 


Figure  51 . 


Red  Agent  Movement  Desire. 
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□  Pythagoras  C:iThesis.Path*gotuoosr«esPythSOJwCafgoXtet.*ml 


Figure  53. 


Shore  Agent  Speed  Property. 
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□  Pythagoras:  CnThesrsiPathegoruousf  Hes.PytnsoJwCargoXlBf.xml 
Overflow  Terrain  Weapon  Sidedness  Sensor  Comms  Aoent  Attribute  Changer  Alternate  Behavior  MOtJ 

Hew 
[  aom 

Delete 


Marne:  [Shore  |  Lest  Modified:  |  | 

:  Descnpfion:  |  Landing  site  I 


Agent  List 
Blue 
Red 
Shore 


Figure  54 . 


Shore  Agent  Movement  Desire, 


Figure  55. 


Cargo  Alternate  Behavior  Speed  Property. 


153 


R  Pythagoras:  C:\ThesisiPathegomousFilestPythSOJwCargoXfer.xml 
Overview  Terrain  Weapon  Sidedness  Sensor  Comms  Agent  Attribute  Changer  Alternate  Behavior  MOE 

New 
J|  Clone 
Delete 


Name:  Cargo  Last  Modified: 

Description: 

Weapon  Possession  Engagement  Desire  Sensor  Possession  J  Comm  Possession  Side  Property  Attributes-]  Resources  ^Triggers 

Positon  Property  Other  Properties  Speed  Property  Movement  Desire  Terrain  Preference 

□  Use  Previous  Behavior 


Movement  Method:  Average  Desire  ▼ 


Title 

%/Count/Force ... 

VCount/Force 

Desire 

Desire  Tolerance 

Distance 

Distance  Tolera. 

Toward  The  Leader  If  Faither  Than 

0.0 

0.0 

0.0 

0.0 

Away  From  The  Leade-  If  Closer  Than 

0.0 

0.0 

0.0 

0.0 

Toward  Closest  Unit  Member  If  Farther  Than 

0.0 

0.0 

0.0 

0.0 

Away  From  Closest  Unit  Member  If  Closer  T. 

0.0 

0.0 

0.0 

0.0 

Toward  Furthest  Unit  Member  II  Farther  Thar 

0.0 

0.0 

0.0 

0.0 

Toward  Closest  Frienc  If  Farther  Than 

0.0 

0.0 

0.0 

00 

Away  From  Closest  Friend  If  Closer  Than 

0.0 

0.0 

0.0 

0.0 

Toward  Furthest  Friend  If  Farmer  Tnan 

0.0 

0.0 

0.0 

0.0 

Toward  Injured  Friend  (Fraction  Health) 

0.0 

00 

0.0 

0.0 

0.0 

00 

Toward  Needing  Fuel 

0.0 

0.0 

0.0 

0.0 

Toward  Needing  Resourcex 

100.0 

10.0 

10.0 

5.0 

Toward  Needing  ResourceY 

00 

no 

too 

00 

Toward  Needing  ResourceZ 

0.0 

0.0 

0.0 

0.0 

Toward  Grvmg  Fuel 

0.0 

0.0 

0.0 

0.0 

Toward  Giving  ResourceX 

00 

00 

00 

00 

Toward  Ghrina  ResourceY 

0.0 

0.0 

00 

0.0 

Toward  Giving  ResourceZ 

0.0 

0.0 

0.0 

0.0 

Toward  Nearest  Enemy  If  Farther  Than 

0.0 

0.0 

0.0 

0.0 

Away  From  Nearest  Enemy  If  Closer  Than 

0.0 

0.0 

0.0 

0.0 

Toward  Nearest  Enemy  If  Fewer  Than  Count 

0 

0 

0.0 

0.0 

0.0 

0.0 

Away  From  Nearest  Enemy  If  More  Than  Co. 

0 

0 

0.0 

0.0 

0.0 

0.0 

Toward  Nearest  Enemy  If  Force  Ratio  More  ... 

0.0 

0.0 

0.0 

0.0 

toTo 

0.0 

hwayFrom  Nearest  Eremy  If  Force  Ratio  L 

0.0 

0.0 

£0 

0.0 

00 

0.0 

Toward  Next  Waypoint 

0.0 

0.0 

0.0 

0.0 

Toward  Final  Objectrve 

0.0 

0.0 

Maintain  Last  Course 

0.0 

0.0 

Select  Random  Direction 

0.0 

0.0 

Stay  m  olace 

0.0 

0.0 

Alternative  Behavior 

WfTiAL 

Cargo 


Figure  56. 


Cargo  Alternate  Behavior  Movement  Desire. 


154 


□  Pythagoras:  C'JhestsPaihegwuousfilesiPythSOJwCargoXler.xinl 
Overview  \  Terrain  Weapon  Sidedness  Sensor  Comms  |  Agent  |  Attribute  Changer  Alternate  Behavior  MOE 


Name:  MOE 


Last  Modified:  4/19/10  9: 


Description:  |cargoXfet 
MOE  Setting 


Recorttng  Method 


MOE  lor  agents: 

Blue 

Shore 


Figure  57.  MOE  for  Model  Iterations. 


Forces  C2  Plans  |  Ops  Plans  |  Mission  Plans  |  Track/Region  Editor 

Commander  Archive 

(Drag  a  commander  to  the  command  structure  to  add  a  commander  instance): 

El  Group  Commanders 


Simple  Force  Commander 


&  Simple  Naval  Commander 
E  Ui  WMA  Commanders 

♦  Air  Warfare  Commander 

♦  Anti-Submarine  Warfare  Commander 

♦  Land  Warfare  Commander 
^  Strike  Warfare  Commander 

♦  Surface  Warfare  Commander 


Figure  58.  Blue  Force  and  Warfare  Commanders  Structure. 
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Ferrer 


C?  Plans 


Ops  Plans 


MLssinn  Plans 


TrackrPeginn  Frtitnr 


Aisel  Archive 

(Drag  an  asset  to  the  command  stiuctuie  ot  map  to  add  an  asset  instance); 

-  uS  Facilities 

♦  LJ  AAAs 

♦  Air  8ases 
-  Buildings 

Buldirg  (Large) 

GENERIC  LAND  BASE 
®  LJ  Others 

♦  LJ  SAMs 

-  LJ  Satellites 

-  Ships 

♦  Q  Amphibious  Assaults 

♦  £j  Amphibious  T lanspoits 

♦  LJ  Battle  Cruisers 


»  u  Battleships 
+  Q]  Cargos 
B  'J)  Carriers 

©  CHG  Moskva 
&  CV  Admiral  Kuznatscv 
®  CV  Clemenceau 
©  CVForrestal 
©  CV  Kitty  Hawk 
©  CV  SaratcgalDmg 

□  CVH  Kiev 

□  CVH  Wasp 

□  CVHG  Admiral  Gorshkov 
©  CVN  Enterprise 

©  CVN  Nimilz 
©  CVN  Theodoie  Roosevelt 

♦  LJ  Coast  Guards 

*■  i_|  Combat  Logislicss 

♦  LJ  Command  Ships 

♦  U  Coiveties 

-  Corsets 

0  CG  Acmiral  Zozuya 
0  CGArtietam 

□  CG  Belknap 
0  CG  Kara 

0  CG  Kreste  II 
0  CG  Kynda 
0  CG  Leahy 
0  CG  Pert  Royal 
0  CG  Slava 
0  CG  Ticonderoga 
0  CGN  Long  Beach  185 
0  CGN  Virginia 

-  Destroyers 
0  D  Suffren 

□  DD  Casserd 

0  DD  ChienYang 
0  DD  Dae  Gu 
0  DD  Ft  Yang 
0  DD  Georoes  Leygues 

m  Dr  U  »*>  V amn 


Figure  59.  Blue  Unit  Level  Structure. 
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Forces 


C2  Plans  |  Ops  Plans  |  Mission  Plans  |  Track/Region  Editor  | 


T -craft  Systems 
Med-Resolution  Sensoi  List: 

Detection  Type  Detectable  T argets  Nominal  Max  Ra...  Sensor  Region  Field ... 

RADAR  SURFACE,  LAND. AIR,  S...  15.7552  n/a  n/a 


Sensor 
Skin  Head 


Forces  |  C2  Plans  |  Ops  Plans 

T-craft  Systems 

Signature  List: 

Mission  Plans  |  Track/Region  Edita  | 

Signature 

Detection  Type 

Optical  Vuln 

OPTICAL 

RADAR  Vuln 

RADAR 

Infrared  Vuln 

INFRARED 

Passive  acoustic  Vuln 

PASSIVE  ACOUSTIC 

Active  acoustic  Vuln 

ACTIVE  ACOUSTIC 

Alliance:  |  BLUE 

Command  Structure: 


-  €3AB 

♦  AZ 

□  FTZ 
®  ew 
0  JSM 

□  LAS 

♦  LS 

0  T-craft 

?  Unassigned  Forces 


Figure  60. 


T-craft  Instance  Settings. 


Faces  |  C2  Plans  |  Ops  Plans 

Mission  Plans  | 

Tiack/Region  Edita  | 

LAS  Systems 

Med-Resolution  Sensoi  List: 

@1 

Sensoi 

Detection  Type 

Detectable  Taigets 

Nominal  Max  Ra  . 

Sensa  Region 

Field 

AN/SPY-ID 

RADAR 

SURFACE.  LAND.  AIR.  S 

188.3457 

n/a 

n/a 

Lowlight  TV 

OPTICAL 

SURFACE.  LAND  AIR 

8  9337 

n/a 

n/a 

* 

AN/SQS-53 

PASSIVE  ACOUSTIC 

SUBSURFACE 

10  4000 

n/a 

n/a 

AN/SSQ-104 

ELINT 

SURFACE.  AIR 

535  4221 

AN/SLQ-32(V)3  (ESM  BAND  1) 

EUNT 

SURFACE.  AIR 

153.1351 

n/a 

n/a 

Faces  J  C2  Plans  |  Ops  Plans 

Mission  Plans  |  T lack/R egcn  E  dta  | 

FTZ  Systems 

Signatuie  List: 

Signature 

Detection  Type 

Optical  Vuln 

OPTICAL 

RADAR  Vuln 

RADAR 

Infrared  Vuln 

INFRARED 

Passive  acoustic  Vuln 

PASSIVE  ACOUSTIC 

Active  acoustic  Vuln 

ACTIVE  ACOUSTIC 

Focces  |  C2  Plots  |  Ops  Plans  |  Mission  Plans  |  Tiack/Region  Edita  | 


Aliance:  |  BLUE 
Command  Structure: 

3  43  AB 

♦  A2 

□  sa 

©  GW 
0  JSM 

□  LAS 

♦  LS 

0  T-craft 

*?  Unassigned  Forces 


FTZ  Systems 


Weapon  List: 


Weapon  Systems 

Weapons 

Engageable  Taigets 

Mk41  VLS  (1) 

RIM-66C  Block  III  SM2MR 

AIR 

RIM-66C  Block  II  SM2MR 

AIR 

RIM-6SC  Block  1  SM2MR 

AIR 

BGM-109B  Tomahawk  TA 

SURFACE 

BGM-109C  TLAM  BLOCK  IIA 

LAND 

BGM-109D  TOMAHAWK 

LAND 

RUR-139VL  ASROC 

SUBSURFACE 

Mkl  41 

RGM-84A  Harpoon  A 

SURFACE 

324mm  Mk32  SVTT  Tnple 

Mk46  NEARTIP  LWT 

SUBSURFACE 

Mk50  Barracuda  ALWT 

SUBSURFACE 

127mm/54  Mk45 

1 27mm/54  AP 

LAND.  AIR 

127mm/54  HE 

LAND, AIR 

127mm/54  HEAP 

SURFACE.  LAND 

Max  Range 

Loadout 

90  0000 

53 

90.0000 

10 

400000 

4 

250  0000 

4 

675  0000 

2 

462  0000 

2 

10  0000 

15 

65  0000 

8 

6.0000 

18 

7  0000 

18 

9  0000 

30 

9  0000 

53 

9.0000 

170 

Figure  61. 


Escort  Instance  Settings. 
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Forces 

C2  Plans 

Ops  Plans 

Mission  Plans 

Track/Region  Editor 

1 

Commander  Archive 

(Drag  a  commander  to  the  command  structure  to  add  a  commander  instance): 


Group  Commanders 


□  Simple  Force  Commander 
&  Simple  Naval  Commander 
-  WMA  Commanders 

♦  Air  Warfare  Commander 

♦  Anti-Submarine  Warfare  Commander 

♦  Land  Warfare  Commander 

♦  Strike  Warfare  Commander 

♦  Surface  Warfare  Commander 


Aiance  [RED  3 

Command  Structure: 


-  FtedForceAB 

♦  RedFotceAZ 
O  RFA 
O  RFB 
-  O  RFC 

*  MG-238M  Flogger  H  SQUADRON  <04/25/10  IB. 32:27>  [MIG-238M  FLOGGER  H]  (2| 
$u-24MK  Fencer  D  SQUADRON  <02/19/10  0&29:44>  [SU-24MK  FENCER  D]  |3) 

7  Uriassignedl  Forces 


Figure  62 . 


Red  Force  and  Warfare  Commanders  Structure. 


Forces  |  C2  Plans  |  Ops  Plans  |  Mission  Flans  |  Track/Region  Editcr  | 


Figure  63. 


Red  Unit  Level  Structure. 
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Faces  |  C2Ptans  |  Ops  Plans  |  Mission  Flans  |  Track/RegonErttor  | 


(Drag  an  asset  to  the  command  structure  a  map  to  add  an  asset  nstance) 


.  J  Faciibes 

•  □  SateAes 

•  ■j  Ships 

♦  j  Amphibious  Assaults 

♦  _j  Amphibious  Tianspats 
>;  j  Battle  Dirsas 

♦;  _]  Battleshps 
♦-  lJ  Cagos 
®  □  Canets 

♦  _J  Coast  Goads 

♦  _J  Comba  Logisbcss 

♦  □  Command  Ships 
®  Cj  Corvettes 

a  CJ  Cruisers 
-  Destroyers 
0  DSuflren 
0  DDCassad 
0  DD  Chen  Yang 
0  DDDaeGu 
0  DDFuYang 
0  DD  Georges  Leygues 
0  DD  Han  Yang 
0  DDJecngBi* 

0  DDloYang 
0  DDLudal 

□  mur.lll 

0  DD  Sptuance  (VIS) 

0  DD  Taejon 
0  DDTourvfe 
0  DDG  Aileigh  Bake 
0  DDGBabi 
0  DDG  Charter  F  Adams 
0  DDGFairagul 
0  DDG  Kashin 
0  DDG  Kashin  Mod 
0  DDGKrfd 
0  DDGLuhu 
0  DDG  Sovremenny 
0  DDGUdaioy 
0  DDG  Winston  Church! 
@  □  Frigates 
ffi  _J  Hosptab 

♦  j  Landng  Dafts 

♦  j  LaedngShps 

♦  _|  Parol  Boas 

♦  j  Tankas 

’  □  Subs 


Mane®  |  RED 
Command  Structure: 


3 


-  €3  RedForceAB 

♦  RecFotceAZ 
O  RFA 
^  RFB 
B  O  RFC 

MG-238M  Flogger  H  SQUADRON  <04/25/10 1ft32:27>  [MIG-238M  FLOGGER  H]  (2) 

Su-24MK  Fencer  0  SQUADRON  <02/19/10  08  29:44>  [SU-24MK  FENCER  D]  (3) 

?  U  reassigned  Forces 


Figure  64 . 


Red  Unit  Level  Structure  (cont. ) . 
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Forces  |  C2  Flans  |  Ops  Flans  |  Mission  Plans  |  Track/Region  Editor 


RFA  Systems 

Med-Resolution  Sensor  List: 


Sensor 

Detection  Type 

Detectable  Targets 

Nominal  MaxRa ... 

Sensor  Region 

Field 

Rice  Screen 

RADAR 

SURFACE,  LAND.  AIR,  S... 

71.6143 

n/a 

n/a 

TAMIR 

PASSIVE  ACOUSTIC 

SUBSURFACE 

11  0000 

n/a 

n/a 

4 

s 


Forces  |  C2  Plans  |  Ops  Plans  |  Mission  Plans  |  Track/Region  Editor  | 


RFA  Systems 
Weapon  List: 


HY-2  Triple 

HY-2  Silkworm 

SURFACE 

100mm/56  Single 

1 0Omm/56  Single  DP 

AIR 

Forces  1  C2  Plans  ] 

Ops  Plans  |  Mission  Plans  |  Track/Region  Editor  | 

RFC  Systems 

Signature  List: 

Sgnature 

Detection  Type 

Optical  Vuln 

OPTICAL 

RADAR  Vuln 

Infrared  Vuln 

Passive  acoustic  Vuln 
Active  acoustic  Vuln 

RADAR 

INFRARED 

PASSIVE  ACOUSTIC 
ACTIVE  ACOUSTIC 

Figure  65. 

Hostile 

Max  Range 
60.0000 
5.0000 


Loadout 

6 

30 


ASance:  ffiED  3 

Command  Structure 
-  €3  RedFaceAB 

♦  RedFacg  AZ 

O  I 
O  RFB 
3  O  RFC 

•*  MK5-238M  Flogger  H  SOUAOROM  <04/25/10 18:3227>  (MIG-238M  FL0GGER  H|  |2| 
^  Su-24MK  Fencer  D  SQUADRON  <02/19/10 08:29 44>  (SU-24MK  FENCER  D|  P] 

7  Unasngned  Faces 


Forces  |  C2  Plans  |  Ops  Plans  |  Mission  Plans  |  Track/Region  Editor  | 


MiG  23BM  Flogger  H  SQUADRON  <04/25/10  18:32:27>  Systems 
Med-Resolution  Sensor  List: 


Sensor 

Sirena-3  RWR 
Mk  1  Eyeball 


Forces  |  C2  Plans  | 


Detection  Type 

ELINT 

OPTICAL 


Detectable  T argets  Nominal  Max  Ra..  Sensor  Region 

SURFACE,  LAND. AIR  27  5423  n/a 

SURFACE.  LAND.  AIR  2.2334  n/a 


Ops  Plans  |  Mission  Plans  |  Track/Region  Editor 


Alliance:  flRED  3 


Field 

n/a 

n/a 


MiG-23BM  Flogger  H  SQUADRON  <04/25/10  18:32:27>  Systems 


Signature  List: 


Signature 

Detection  Type 

Optical  Vuln 

OPTICAL 

RADAR  Vuln 

RADAR 

Infrared  Vuln 

INFRARED 

Forces  |  C2  Plans 

Ops  Plans  |  Mission  Plans  |  Track/Region  Editor  | 

Command  Stiuchse: 

-  ^  RedFotceAB 

♦  RedFoiceAZ 
O  RFA 
O  RFB 

B  <S>  RFC _ 


[M6-238M  Flogg-M  H  SQUADRON  04/25/10  IS  3:27,  [MIG238M  FLOGGER  H)  [2|| 


Su  24MK  Fencei  D  SQUADRON  <02/19/10  0829  44>  [SU-24MK  FENCER  0)  [3| 
9  Unassiyied  Foices 


MiG  23BM  Flogger  H  SQUADRON  <04/25/10  18:32:27>  Systems 


Weapon  List: 


Weapon  Systems  Weapons 

Engageable  Targets 

Max  Range 

MiG-238M  Flogger  H  weapo.  AS-7  Kerry 

SURFACE.  LAND 

6  0000 

500kg  Bomb 

SURFACE.  LAND 

2  0000 

S-5K  57mm  Rocket 

SURFACE.  LAND 

2  0000 

AS-10  Karen 

SURFACE 

6.0000 

Figure  66. 
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Forces  C2  Plans  |  Ops  Plans  |  Mission  Plans  |  Track/Region  Editor  | 


Forces  j  C2  Flans  j  Ops  Plans  |  Mission  Plans  j  Track/Region  Editor  | 

Warfare  Commander  Attributes: 

AZ 


Asset  C2  Options  Summary: 
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Sensor 
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LS 
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T  -craft 
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lx 

r 

lx 

Food  |  C2  Plans  Ops  Plans  j  Mosron  Flans  |  ?  lack/Regrsn  Edtor  | 

M  often  j  Commurocstoni  jj 

EMCON  | 

Assured  romans 

AZ 

Command  Contes  Asset: 

GW 

Embarked  Commanders 

AB 

C2  Conneclivitjr. 

Unconsftaned 

Entry  Patameleit: 

Corre.ponddJNmerCrllSm 

1  Embarked  CD Ri  1  OulgcanflMetsa 

je-.  Jneerrsng  Message: 

Forces  |  C2  Plans  |  Ops  Plans  Mission  Plans  |  Track/Region  Ed*or  | 
Mission  Plan  T emplates 

(Drag  a  mission  plan  template  to  the  Command  Structure  to  add  a  new  mission  plan) 

■  Air  Wailare/TMD  Plan 
Q  Aircraft  Alert  Plan 
Q  Antisubmarine  Warfare  Plan 
-  J:  General  Mission  Plan 
0  Non-Recurring  Plan 
Q  Phased  Plan 

0  Recurring  Basic  Aircraft  Mission  Plan 
□  TBM  Salvo  Plan 
D  Intel..  Surv.  &  Recce  Plan 
□  MCM  SIN  Plan 
Q  MCM  Sweep  Plan 
D  Mine  Laying  Plan 
Q  Strike  Warfare  Plan 
Q  Surface  Warfare  Plan 


Akance  {BLUE  3 

Command  Structure 
-  €3  AB 

D  Aircraft  Alert  Plans 
♦  &  General  Mission  Plans 
&  Surf  ace  Warfare  Plans 

□  FTZ 
©  GW 

□  JSM 

□  LAS 


Figure  68. 
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Forces  |  C2  Plans  Ops  Plans  |  Mission  Plans  |  Track/Region  Editor  | 

Motion  |  Communications  |  EMCON  | 

C  Stationary  C  Formation  C  Complex  Formation  Moving 


Complex  Motion  List: 


Motion 

Segment 

Type 

Specified  Motion 

Use 

Default 

Duration 

Duration 

M 

Segment 

Operational 

State 

Segment  Depth  Profile 

T  ransition 
Speed 
(kts) 

T  ransition 

Operational 

State 

Tidnsition  Depth  Profile 

Time  (hrs) 

Area 

REDFORCE  AREA 

1B1 

216.00 

PATROL 

NONE 

NA 

NA 

NA 

21600 

Forces  |  C2  Flans  Ops  Flans  |  Mission  Flans  |  Track/Region  Edfor 


Motion  |  Communications  EMCON 


Forces  |  C2  Plans  Ops  Plans  |  Mission  Plans  |  Track/Region  Editor 
Motion  Communications  |  EMCON  | 


System  Activation  Schedules:  RedFoteeAB 


n 


Percent  Complete:  100% 


Connectivity  Table: 


ALL  ... 

RFA 

RFB 

RFC 

ALL  RED 

X 

RFA 

RFB 

RFC 

Recipients 


Figure  69. 
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Fences  C2  Plans  j  Ops  Plans  |  Mission  Plans  j  T rack/Region  Editor  j 

Warfare  Commander  Attributes: 

RedForce  AZ 


Asset  C2  Options  Summary: 


Asset 

|  Start  Time  (dd:hh:mm:ss) 

End  Time  (dd:hh:mm:ss) 

Sensor 

Weap... 

Motion  Max  Engagements  Max  Sensor  T* 
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0  00:00:00 
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RFB 

0  00:00:00 

9  00:00:00 

lx 

lx 
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RFC 
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lx 

lx 
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Forces  |  C2  Plans  Ops  Plans  |  Mission  Plans  |  Track /Regs 
Motion  j  Communications  i|  EMCON  | 

Assured  Comms:  RedFotceAZ 

Command  Center  Asset:  RFA 

Embarked  Commanders:  RedFoteeAB 


Entry  Parameters: 


Alliance:  [RED 

Command  Structure: 


U 


€3  RedForce  AB 
♦  RedForce  AZ 
O  RFA 
O  RFB 
Ct  O  RFC 
*?  Unassigned  Forces 


Correspondent  Name^Cal  Sign  |  Embarked  CORs 


RFB 

RFC 


I  Outgoing  Messages  |  Incommg  Messages  | 


Mission  Plan  Templates 

(Drag  a  mission  plan  template  to  the  Command  Structure  to  add  a  new  mission  plan): 

□  Air  Warfare/TMD  Plan 
D  Aircralt  Alert  Plan 

Antisubmarine  Warfare  Plan 
Q  General  Mission  Plan 
0  Non-Recurring  Plan 
0  Phased  Plan 

0  Recurring  Basic  Aircraft  Missioi 
□  TBM  Salvo  Plan 
Q  Intel..  Suiv.  t  Recce  Plan 

□  MCM  SIN  Plan 
D  MCM  Sweep  Plan 
0  Mine  Laying  Plan 
Q  Strike  Warfare  Plan 
Q  Surface  Warfare  Plan 


^  RedFoteeAB 

O  Aircraft  Alert  Plans 
&  General  Mission  Plans 
&  Surface  Warfare  Flans 
O  RFA 
O  RF8 
ffl  O  RFC 
?  Unassigned  Forces 


Figure  70 
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Figure  72.  T-craft  Mover  Manager  Event  Graph  Object. 


Figure  73.  Generic  Referee  Event  Graph  Object. 
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Figure  7 4  . 


Generic  Mediator  Event  Graph  Object. 
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Figure  76.  Return  to  Base  Event  Graph  Object. 
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Figure  77.  Escort  Random  Mover  Manager  Event  Graph 

Ob j  ect . 


167 


SimTime 

Event 

State  (S) 

Cargo  (S) 

Damage  (D) 

Mission  Flag  (M) 

Shore  Cargo  (SC) 

[Next  Event] 

0.00 

Run 

DBK 

0.00 

0.00 

0 

0.00 

[0,  Load] 

0.00 

Load 

DBK 

0.00 

0.00 

0 

0.00 

[0,  Transit] 

0.00 

Transit 

DBK 

0.00 

0.00 

0 

0.00 

[0,  DBK  to  SBO] 

0.00 

DBK  to  SBO 

DBK 

0.00 

0.00 

0 

0.00 

[0,  Start  Move] 

0.00 

Start  Move 

DBK 

0.00 

0.00 

0 

0.00 

[5,  End  Move;  1  Enter  Range;  5  Exit  Range] 

1.00 

Enter  Range 

DBK 

0.00 

0.00 

0 

0.00 

[5,  End  Move;  5  Exit  Range;  2  Detect] 

2.00 

Detect 

DBK 

0.00 

0.00 

0 

0.00 

[5,  End  Move;  5  Exit  Range;  2  Attack] 

2.00 

Attack 

DBK 

0.00 

0.00 

0 

0.00 

[5,  End  Move;  5  Exit  Range;  2  BDA] 

2.00 

BDA 

DBK 

0.00 

0.00 

0 

0.00 

[5,  End  Move;  5  Exit  Range] 

5.00 

End  Move 

DBK 

0.00 

0.00 

0 

0.00 

[5,  State;  5  Exit  Range] 

5.00 

State  A 

SBO 

0.00 

0.00 

0 

0.00 

[5,  Exit  Range;  5  Load] 

5.00 

Load 

SBO 

360.00 

0.00 

0 

0.00 

[5,  Exit  Range;  15,  Transit] 

5.00 

Exit  Range 

SBO 

360.00 

0.00 

0 

0.00 

[5,  Un-Detect;  15,  Transit] 

5.00 

Un-Detect 

SBO 

360.00 

0.00 

0 

0.00 

[15,  Transit] 

15.00 

Transit 

SBO 

360.00 

0.00 

0 

0.00 

[15,  SBO  to  SHO] 

15.00 

SBO  to  SHO 

SBO 

360.00 

0.00 

0 

0.00 

[1 5,  Start  Move] 

15.00 

Start  Move 

SBO 

360.00 

0.00 

0 

0.00 

[20,  End  Move;  20  ,Exit  Range;  16,  Enter  Range] 

16.00 

Enter  Range 

SBO 

360.00 

0.00 

0 

0.00 

[20,  End  Move;  20,  Exit  Range;  17,  Detect] 

17.00 

Detect 

SBO 

360.00 

0.00 

0 

0.00 

[20,  End  Move;  20,  Exit  Range;  17,  Attack] 

17.00 

Attack 

SBO 

360.00 

0.00 

0 

0.00 

[20,  End  Move;  20,  Exit  Range;  17,  BDA] 

17.00 

BDA 

SBO 

360.00 

0.30 

0 

0.00 

[20,  End  Move;  20,  Exit  Range] 

20.00 

End  Move 

SBO 

360.00 

0.30 

0 

0.00 

[20,  State;  20,  Exit  Range] 

20.00 

Exit  Range 

SBO 

360.00 

0.30 

0 

0.00 

[20,  State;  20,  Un-Detect] 

20.00 

Un-Detect 

SBO 

360.00 

0.30 

0 

0.00 

[20,  State] 

20.00 

State  A 

SHO 

360.00 

0.30 

0 

0.00 

[20,  Unload] 

20.00 

Unload 

SHO 

0.00 

0.30 

0 

360.00 

[30,  Transit] 

30.00 

Transit 

SHO 

0.00 

0.30 

0 

360.00 

[30,  SHO  to  SBO] 

30.00 

SHO  to  SBO 

SHO 

0.00 

0.30 

0 

360.00 

[30,  Start  Move] 

30.00 

Start  Move 

SHO 

0.00 

0.30 

0 

360.00 

[35,  End  Move;  35  Exit  Range;  31  Enter  Range] 

31.00 

Enter  Range 

SHO 

0.00 

0.30 

0 

360.00 

[35,  End  Move;  35,  Exit  Range;  32,  Detect] 

32.00 

Detect 

SHO 

0.00 

0.30 

0 

360.00 

[35,  End  Move;  35,  Exit  Range;  32,  Attack] 

32.00 

Attack 

SHO 

0.00 

0.30 

0 

360.00 

[35,  End  Move;  35,  Exit  Range;  32,  BDA] 

32.00 

BDA 

SHO 

0.00 

0.30 

0 

360.00 

[35,  End  Move;  35,  Exit  Range] 

35.00 

End  Move 

SHO 

0.00 

0.30 

0 

360.00 

[35,  State;  35,  Exit  Range] 

35.00 

State  A 

SBO 

0.00 

0.30 

0 

360.00 

[35,  Exit  Range;  35,  Repair] 

35.00 

Repair 

SBO 

0.00 

0.00 

0 

360.00 

[35,  Exit  Range;  55,  Load] 

35.00 

Exit  Range 

SBO 

0.00 

0.00 

0 

360.00 

[55,  Load;  35  Un-Detect] 

35.00 

Un-Detect 

SBO 

0.00 

0.00 

0 

360.00 

[55,  Load] 

55.00 

Load 

SBO 

700.00 

0.00 

0 

360.00 

[65,  Transit] 

65.00 

Transit 

SBO 

700.00 

0.00 

0 

360.00 

[65,  SBO  to  SHO] 

65.00 

SBO  to  SHO 

SBO 

700.00 

0.00 

0 

360.00 

[65,  Start  Move] 

65.00 

Start  Move 

SBO 

700.00 

0.00 

0 

360.00 

[70,  End  Move;  70  ,Exit  Range;  66,  Enter  Range] 

66.00 

Enter  Range 

SBO 

700.00 

0.00 

0 

360.00 

[70,  End  Move;  70,  Exit  Range;  67,  Detect] 

67.00 

Detect 

SBO 

700.00 

0.00 

0 

360.00 

[70,  End  Move;  70,  Exit  Range;  67,  Attack] 

67.00 

Attack 

SBO 

700.00 

0.00 

0 

360.00 

[70,  End  Move;  70,  Exit  Range;  67,  BDA] 

67.00 

BDA 

SBO 

700.00 

0.12 

0 

360.00 

[70,  End  Move;  70,  Exit  Range] 

70.00 

End  Move 

SBO 

700.00 

0.12 

0 

360.00 

[70,  State;  70,  Exit  Range] 

70.00 

Exit  Range 

SBO 

700.00 

0.12 

0 

360.00 

[70,  State;  70,  Un-Detect] 

70.00 

Un-Detect 

SBO 

700.00 

0.12 

0 

360.00 

[70,  State] 

70.00 

State  A 

SHO 

700.00 

0.12 

0 

360.00 

[70,  Unload] 

70.00 

Unload 

SHO 

0.00 

0.12 

0 

1060.00 

[80,  Transit] 

80.00 

Transit 

SHO 

0.00 

0.12 

0 

1060.00 

[80,  SHO  to  SBO] 

80.00 

SHO  to  SBO 

SHO 

0.00 

0.12 

0 

1060.00 

[80,  Start  Move] 

80.00 

Start  Move 

SHO 

0.00 

0.12 

0 

1060.00 

[85,  End  Move;  85  Exit  Range;  81  Enter  Range] 

81.00 

Enter  Range 

SHO 

0.00 

0.12 

0 

1060.00 

[85,  End  Move;  85,  Exit  Range;  82,  Detect] 

82.00 

Detect 

SHO 

0.00 

0.12 

0 

1060.00 

[85,  End  Move;  85,  Exit  Range;  82,  Attack] 

82.00 

Attack 

SHO 

0.00 

0.12 

0 

1060.00 

[85,  End  Move;  85,  Exit  Range;  82,  BDA] 

82.00 

BDA 

SHO 

0.00 

0 

1060.00 

[85,  End  Move;  85,  Exit  Range;  82,  Killed] 

82.00 

Killed 

SHO 

0.00 

0 

1060.00 

[85,  End  Move;  85,  Exit  Range;  82,  STOP] 

82.00 

STOP 

SHO 

0.00 

0 

1060.00 

o 

ii 

X 

Hand  Simulation  Design  Point  1. 
168 


Figure  78 
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700.00 

0.12 

0 

660.00 

[70,  Unload] 

70.00 

Unload 

SHO 

0.00 

0.12 

0 

1360.00 

[80,  Transit] 

80.00 

Transit 

SHO 

0.00 

0.12 

0 

1360.00 

[80,  SHO  to  SBO] 

80.00 

SHO  to  SBO 

SHO 

0.00 

0.12 

0 

1360.00 

[80,  Start  Move] 

80.00 

Start  Move 

SHO 

0.00 

0.12 

0 

1360.00 

[85,  End  Move;  85  Exit  Range;  81  Enter  Range] 

81.00 

Enter  Range 

SHO 

0.00 

0.12 

0 

1360.00 

[85,  End  Move;  85,  Exit  Range;  82,  Detect] 

82.00 

Detect 

SHO 

0.00 

0.12 

0 

1360.00 

[85,  End  Move;  85,  Exit  Range;  82,  Attack] 

82.00 

Attack 

SHO 

0.00 

0.12 

0 

1360.00 

[85,  End  Move;  85,  Exit  Range;  82,  BDA] 

82.00 

BDA 

SHO 

0.00 

0.72 

0 

1360.00 

[85,  End  Move;  85,  Exit  Range;  82,  Killed] 

85.00 

End  Move 

SHO 

0.00 

0.72 

0 

1360.00 

[85,  State;  85,  Exit  Range] 

85.00 

State  A 

SBO 

0.00 

0.72 

0 

1360.00 

[85,  Exit  Range;  85,  Repair] 

85.00 

Repair 

SBO 

0.00 

0.00 

0 

1360.00 

[85,  Exit  Range;  105,  Load] 

85.00 

Exit  Range 

SBO 

0.00 

0.00 

0 

1360.00 

[105,  Load;  85  Un-Detect] 

85.00 

Un-Detect 

SBO 

0.00 

0.00 

0 

1360.00 

[105,  Load] 

105.00 

Load 

SBO 

400.00 

0.00 

0 

1360.00 

[1 1 5,  T ransit] 

115.00 

Transit 

SBO 

400.00 

0.00 

0 

1360.00 

[11 5, SBO  to  SHO] 

115.00 

SBO  to  SHO 

SBO 

400.00 

0.00 

0 

1360.00 

[115,  Start  Move] 

115.00 

Start  Move 

SBO 

400.00 

0.00 

0 

1360.00 

[120,  End  Move;  120  .Exit  Range;  116,  Enter  Range] 

116.00 

Enter  Range 

SBO 

400.00 

0.00 

0 

1360.00 

[120,  End  Move;  120,  Exit  Range;117,  Detect] 

117.00 

Detect 

SBO 

400.00 

0.00 

0 

1360.00 

[120,  End  Move;  120,  Exit  Range;  117,  Attack] 

117.00 

Attack 

SBO 

400.00 

0.00 

0 

1360.00 

[120,  End  Move;  120,  Exit  Range;  117,  BDA] 

117.00 

BDA 

SBO 

400.00 

0.32 

0 

1360.00 

[120,  End  Move;  120,  Exit  Range] 

120.00 

End  Move 

SBO 

400.00 

0.32 

0 

1360.00 

[120,  State;  120,  Exit  Range] 

120.00 

Exit  Range 

SBO 

400.00 

0.32 

0 

1360.00 

[120,  State;  120,  Un-Detect] 
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SimTime  Event  State  (S)  Cargo  (S) 

Damage  (D) 

Mission  Flag  (M)  Shore  Cargo  (SC)  [Next  Event] 

0.00 

Run 

DBK 

0.00 

0.00 

0 

0.00 

[0,  Load] 

0.00 

Load 

DBK 

750.00 

0.00 

0 

0.00 

[0,  Transit] 

0.00 

T  ransit 

DBK 

750.00 

0.00 

0 

0.00 

[0,  DBK  to  SBO] 

0.00 

DBK  to  SBO 

DBK 

750.00 

0.00 

0 

0.00 

[0,  Start  Move] 

0.00 

Start  Move 

DBK 

750.00 

0.00 

0 

0.00 

[5,  End  Move;  1  Enter  Range;  5  Exit  Range] 

1.00 

Enter  Range 

DBK 

750.00 

0.00 

0 

0.00 

[5,  End  Move;  5  Exit  Range;  2  Detect] 

2.00 

Detect 

DBK 

750.00 

0.00 

0 

0.00 

[5,  End  Move;  5  Exit  Range;  2  Attack] 

2.00 

Attack 

DBK 

750.00 

0.00 

0 

0.00 

[5,  End  Move;  5  Exit  Range;  2  BDA] 

2.00 

BDA 

DBK 

750.00 

0.00 

0 

0.00 

[5,  End  Move;  5  Exit  Range] 

5.00 

End  Move 

DBK 

750.00 

0.00 

0 

0.00 

[5,  State;  5  Exit  Range] 

5.00 

State  A 

SBO 

750.00 

0.00 

0 

0.00 

[5,  Exit  Range;  5  Transit] 

5.00 

Exit  Range 

SBO 

750.00 

0.00 

0 

0.00 

[5,  Transit;  5,  Un-Detect] 

5.00 

T  ransit 

SBO 

750.00 

0.00 

0 

0.00 

[5,  SBO  to  SHO] 

5.00 

SBO  to  SHO 

SBO 

750.00 

0.00 

0 

0.00 

[5,  Start  Move] 

5.00 

Start  Move 

SBO 

750.00 

0.00 

0 

0.00 

[10,  End  Move;  10  .Exit  Range;  6,  Enter  Range] 

6.00 

Enter  Range 

SBO 

750.00 

0.00 

0 

0.00 

[10,  End  Move;  10,  Exit  Range;  7,  Detect] 

7.00 

Detect 

SBO 

750.00 

0.00 

0 

0.00 

[10,  End  Move;  10,  Exit  Range;  7,  Attack] 

7.00 

Attack 

SBO 

750.00 

0.00 

0 

0.00 

[10,  End  Move;  10,  Exit  Range;  17,  BDA] 

7.00 

BDA 

SBO 

750.00 

0.30 

0 

0.00 

[10,  End  Move;  10,  Exit  Range] 

10.00 

End  Move 

SBO 

750.00 

0.30 

0 

0.00 

[10,  State;  10,  Exit  Range] 

10.00 

Exit  Range 

SBO 

750.00 

0.30 

0 

0.00 

[10,  State;  10,  Un-Detect] 

10.00 

Un-Detect 

SBO 

750.00 

0.30 

0 

0.00 

[10,  State] 

10.00 

State  A 

SBO 

750.00 

0.30 

0 

0.00 

[10,  Repair] 

10.00 

Repair 

SBO 

0.00 

0.00 

0 

0.00 

[30,  Load] 

30.00 

Load 

SBO 

360.00 

0.00 

0 

0.00 

[30,  Transit] 

30.00 

T  ransit 

SBO 

360.00 

0.00 

0 

0.00 

[30,  SBO  to  SHO] 

30.00 

SBO  to  SHO 

SBO 

360.00 

0.00 

0 

0.00 

[30,  Start  Move] 

30.00 

Start  Move 

SBO 

360.00 

0.00 

0 

0.00 

[35,  End  Move;  35  .Exit  Range;  31,  Enter  Range] 

31.00 

Enter  Range 

SBO 

360.00 

0.00 

0 

0.00 

[35,  End  Move;  35,  Exit  Range;  32,  Detect] 

32.00 

Detect 

SBO 

360.00 

0.00 

0 

0.00 

[35,  End  Move;  35,  Exit  Range;  32,  Attack] 

32.00 

Attack 

SBO 

360.00 

0.00 

0 

0.00 

[35,  End  Move;  35,  Exit  Range;  32,  BDA] 

32.00 

BDA 

SBO 

360.00 

0.12 

0 

0.00 

[35,  End  Move;  35,  Exit  Range] 

35.00 

End  Move 

SBO 

360.00 

0.12 

0 

0.00 

[35,  State;  35,  Exit  Range] 

35.00 

Exit  Range 

SBO 

360.00 

0.12 

0 

0.00 

[35,  State;  35,  Un-Detect] 

35.00 

Un-Detect 

SBO 

360.00 

0.12 

0 

0.00 

[35,  State] 

35.00 

State  A 

SHO 

360.00 

0.12 

0 

0.00 

[35,  Unload] 

35.00 

Unload 

SHO 

0.00 

0.12 

0 

360.00 

[45,  Transit] 

45.00 

T  ransit 

SHO 

0.00 

0.12 

0 

360.00 

[45,  SHO  to  SBO] 

45.00 

SHO  to  SBO 

SHO 

0.00 

0.12 

0 

360.00 

[45,  Start  Move] 

45.00 

Start  Move 

SHO 

0.00 

0.12 

0 

360.00 

[50,  End  Move;  50,  Exit  Range;  46,  Enter  Range] 

46.00 

Enter  Range 

SHO 

0.00 

0.12 

0 

360.00 

[50,  End  Move;  50,  Exit  Range;  47,  Detect] 

47.00 

Detect 

SHO 

0.00 

0.12 

0 

360.00 

[50,  End  Move;  50,  Exit  Range;  47,  Attack] 

47.00 

Attack 

SHO 

0.00 

0.12 

0 

360.00 

[50,  End  Move;  50,  Exit  Range;  47,  BDA] 

47.00 

BDA 

SHO 

0.00 

0.12 

0 

360.00 

[50,  End  Move;  50,  Exit  Range] 

50.00 

End  Move 

SHO 

0.00 

0.12 

0 

360.00 

[50,  State;  50,  Exit  Range] 

50.00 

State  A 

SBO 

0.00 

0.12 

0 

360.00 

[50,  Exit  Range;  50,  Load] 

50.00 

Exit  Range 

SBO 

0.00 

0.12 

0 

360.00 

[50,  Load,  50,  Un-Detect] 

50.00 

Un-Detect 

SBO 

0.00 

0.12 

0 

360.00 

[50,  Load] 

50.00 

Load 

SBO 

700.00 

0.12 

0 

360.00 

[60,  Transit] 

60.00 

T  ransit 

SBO 

700.00 

0.12 

0 

360.00 

[60,  SBO  to  SHO] 

60.00 

SBO  to  SHO 

SBO 

700.00 

0.12 

0 

360.00 

[60,  Start  Move] 

60.00 

Start  Move 

SBO 

700.00 

0.12 

0 

360.00 

[65,  End  Move;  65  .Exit  Range;  61,  Enter  Range] 

61.00 

Enter  Range 

SBO 

700.00 

0.12 

0 

360.00 

[65,  End  Move;  65,  Exit  Range;  62,  Detect] 

62.00 

Detect 

SBO 

700.00 

0.12 

0 

360.00 

[65,  End  Move;  65,  Exit  Range;  62,  Attack] 

62.00 

Attack 

SBO 

700.00 

0.12 

0 

360.00 

[65,  End  Move;  65,  Exit  Range;  62,  BDA] 

62.00 

BDA 

SBO 

360.00 

[65,  End  Move;  65,  Exit  Range;  62,  Killed] 

62.00 

Killed 

SBO 

700.00 

H5- 

° 

360.00 

[65,  End  Move;  65,  Exit  Range;  65,  Un-Detect;  62,  STOP] 

62.00 

STOP 

SBO 

700.00 

° 

360.00 

o' 

ii 

X 

Figure  80. 
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SimTime 

Event 

State  (S) 

Cargo  (S) 

Damage  (D) 

Mission  Flag  (M) 

Shore  Cargo  (SC) 

[Next  Event] 

0.00 

Run 

SBO 

0.00 

0.00 

0 

0.00 

[0,  Load] 

0.00 

Load 

SBO 

300.00 

0.00 

0 

0.00 

[0,  Transit] 

0.00 

Transit 

SBO 

300.00 

0.00 

0 

0.00 

[0,  SBO  to  SHO] 

0.00 

SBO  to  SHO 

SBO 

300.00 

0.00 

0 

0.00 

[0,  Start  Move] 

0.00 

Start  Move 

SBO 

300.00 

0.00 

0 

0.00 

[5,  End  Move;  5,  Exit  Range;  1,  Enter  Range] 

1.00 

Enter  Range 

SBO 

300.00 

0.00 

0 

0.00 

[5,  End  Move;  5,  Exit  Range;  2,  Detect] 

2.00 

Detect 

SBO 

300.00 

0.00 

0 

0.00 

[5,  End  Move;  5,  Exit  Range;  2,  Attack] 

2.00 

Attack 

SBO 

300.00 

0.00 

0 

0.00 

[5,  End  Move;  5,  Exit  Range;  2,  BDA] 

2.00 

BDA 

SBO 

300.00 

0.50 

0 

0.00 

[5,  End  Move;  5,  Exit  Range] 

5.00 

Exit  Range 

SBO 

300.00 

0.50 

0 

0.00 

[5,  End  Move;  5,  Un-Detect] 

5.00 

Un-Detect 

SBO 

300.00 

0.50 

0 

0.00 

[5,  End  Move] 

5.00 

End  Move 

SBO 

300.00 

0.50 

0 

0.00 

[5,  State] 

5.00 

State  A 

SHO 

300.00 

0.50 

0 

0.00 

[5,  Unload] 

5.00 

Unload 

SHO 

0.00 

0.50 

0 

300.00 

[15,  Transit] 

15.00 

T  ransit 

SHO 

0.00 

0.50 

0 

300.00 

[15,  SHO  to  SBO] 

15.00 

SHO  to  SBO 

SHO 

0.00 

0.50 

0 

300.00 

[1 5,  Start  Move] 

15.00 

Start  Move 

SHO 

0.00 

0.50 

0 

300.00 

[20,  End  Move;  20,  Exit  Range;  16,  Enter  Range] 

16.00 

Enter  Range 

SHO 

0.00 

0.50 

0 

300.00 

[20,  End  Move;  20,  Exit  Range;  17,  Detect] 

17.00 

Detect 

SHO 

0.00 

0.50 

0 

300.00 

[20,  End  Move;  20,  Exit  Range;  17,  Attack] 

17.00 

Attack 

SHO 

0.00 

0.50 

0 

300.00 

[20,  End  Move;  20,  Exit  Range;  17,  BDA] 

17.00 

BDA 

SHO 

0.00 

0.55 

0 

300.00 

[20,  End  Move;  20,  Exit  Range] 

20.00 

Exit  Range 

SHO 

0.00 

0.55 

0 

300.00 

[20,  End  Move;  20,  Un-Detect] 

20.00 

End  Move 

SHO 

0.00 

0.55 

0 

300.00 

[20,  State;  20,  Un-Detect] 

20.00 

State  A 

SBO 

0.00 

0.55 

0 

300.00 

[20,  Repair] 

20.00 

Repair 

SBO 

0.00 

0.00 

0 

300.00 

[40,  Load] 

40.00 

Load 

SBO 

550.00 

0.00 

0 

300.00 

[40,  T ransit] 

40.00 

Transit 

SBO 

550.00 

0.00 

0 

300.00 

[40,  SBO  to  SHO] 

40.00 

SBO  to  SHO 

SBO 

550.00 

0.00 

0 

300.00 

[0,  Start  Move] 

40.00 

Start  Move 

SBO 

550.00 

0.00 

0 

300.00 

[45,  End  Move;  45,  Exit  Range;  41,  Enter  Range] 

41.00 

Enter  Range 

SBO 

550.00 

0.00 

0 

300.00 

[45,  End  Move;  45,  Exit  Range;  42,  Detect] 

42.00 

Detect 

SBO 

550.00 

0.00 

0 

300.00 

[45,  End  Move;  45,  Exit  Range;  42,  Attack] 

42.00 

Attack 

SBO 

550.00 

0.00 

0 

300.00 

[45,  End  Move;  45,  Exit  Range;  42,  BDA] 

42.00 

BDA 

SBO 

550.00 

0.07 

0 

300.00 

[45,  End  Move;  45,  Exit  Range] 

45.00 

Exit  Range 

SBO 

550.00 

0.07 

0 

300.00 

[45,  End  Move;  45,  Un-Detect] 

45.00 

Un-Detect 

SBO 

550.00 

0.07 

0 

300.00 

[45,  End  Move] 

45.00 

End  Move 

SBO 

550.00 

0.07 

0 

300.00 

[45,  State] 

45.00 

State  A 

SHO 

550.00 

0.07 

0 

300.00 

[45,  Unload] 

45.00 

Unload 

SHO 

0.00 

0.07 

0 

850.00 

[45,  Transit] 

45.00 

Transit 

SHO 

0.00 

0.07 

0 

850.00 

[45,  SHO  to  SBO] 

45.00 

SHO  to  SBO 

SHO 

0.00 

0.07 

0 

850.00 

[45,  Start  Move] 

45.00 

Start  Move 

SHO 

0.00 

0.07 

0 

850.00 

[50,  End  Move;  50,  Exit  Range;  46,  Enter  Range] 

46.00 

Enter  Range 

SHO 

0.00 

0.07 

0 

850.00 

[50,  End  Move;  50,  Exit  Range;  47,  Detect] 

47.00 

Detect 

SHO 

0.00 

0.07 

0 

850.00 

[50,  End  Move;  50,  Exit  Range;  47,  Attack] 

47.00 

Attack 

SHO 

0.00 

0.07 

0 

850.00 

[50,  End  Move;  50,  Exit  Range;  47,  BDA] 

47.00 

BDA 

SHO 

0.00 

0.12 

0 

850.00 

[50,  End  Move;  50,  Exit  Range] 

50.00 

Exit  Range 

SHO 

0.00 

0.12 

0 

850.00 

[50,  End  Move;  50,  Un-Detect] 

50.00 

Un-Detect 

SHO 

0.00 

0.12 

0 

850.00 

[50,  End  Move] 

50.00 

End  Move 

SHO 

0.00 

0.12 

0 

850.00 

[50,  State] 

50.00 

State  A 

SBO 

0.00 

0.12 

0 

850.00 

[50,  Load] 

50.00 

Load 

SBO 

680.00 

0.12 

0 

850.00 

[50,  Transit] 

50.00 

Transit 

SBO 

680.00 

0.12 

0 

850.00 

[50,  SBO  to  SHO] 

50.00 

SBO  to  SHO 

SBO 

680.00 

0.12 

0 

850.00 

[50,  Start  Move] 

50.00 

Start  Move 

SBO 

680.00 

0.12 

0 

850.00 

[55,  End  Move;  55,  Exit  Range;  51 ,  Enter  Range] 

51.00 

Enter  Range 

SBO 

680.00 

0.12 

0 

850.00 

[55,  End  Move;  55,  Exit  Range;  52,  Detect] 

52.00 

Detect 

SBO 

680.00 

0.12 

0 

850.00 

[55,  End  Move;  55,  Exit  Range;  52,  Attack] 

52.00 

Attack 

SBO 

680.00 

0.12 

0 

850.00 

[55,  End  Move;  55,  Exit  Range;  52,  BDA] 

52.00 

BDA 

SBO 

680.00 

0.37 

0 

850.00 

[55,  End  Move;  55,  Exit  Range] 

55.00 

Exit  Range 

SBO 

680.00 

0.37 

0 

850.00 

[55,  End  Move;  55,  Un-Detect] 

55.00 

Un-Detect 

SBO 

680.00 

0.37 

0 

850.00 

[55,  End  Move] 

55.00 

End  Move 

SBO 

680.00 

0.37 

0 

850.00 

[55,  State] 

55.00 

State  A 

SHO 

680.00 

0.37 

0 

850.00 

[55,  Unload] 

55.00 

Unload 

SHO 

0.00 

0.37 

0 

1530.00 

[65,  Transit] 

65.00 

Transit 

SHO 

0.00 

0.37 

0 

1530.00 

[65,  SHO  to  SBO] 

65.00 

SHO  to  SBO 

SHO 

0.00 

0.37 

0 

1530.00 

[65,  Start  Move] 

65.00 

Start  Move 

SHO 

0.00 

0.37 

0 

1530.00 

[70,  End  Move;  70,  Exit  Range;  66,  Enter  Range] 

66.00 

Enter  Range 

SHO 

0.00 

0.37 

0 

1530.00 

[70,  End  Move;  70,  Exit  Range;  67,  Detect] 

67.00 

Detect 

SHO 

0.00 

0.37 

0 

1530.00 

[70,  End  Move;  70,  Exit  Range;  67,  Attack] 

67.00 

Attack 

SHO 

0.00 

0.37 

0 

1530.00 

[70,  End  Move;  70,  Exit  Range;  67,  BDA] 

67.00 

BDA 

SHO 

0.00 

0.77 

0 

1530.00 

[70,  End  Move;  70,  Exit  Range] 

70.00 

Exit  Range 

SHO 

0.00 

0.77 

0 

1530.00 

[70,  End  Move;  70,  Un-Detect] 

70.00 

Un-Detect 

SHO 

0.00 

0.77 

0 

1530.00 

[70,  End  Move] 

70.00 

End  Move 

SHO 

0.00 

0.77 

0 

1530.00 

[70,  State] 

70.00 

State  A 

SBO 

0.00 

0.77 

0 

1530.00 

[70,  Repair] 

Figure  81.  Hand  Simulation  Design  Point  5. 
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SimTime 

Event 

State  (S) 

Cargo  (S) 

Damage  (D) 

Mission  Flag  (M) 

Shore  Cargo  (SC) 

[Next  Event] 

0.00 

Run 

SBO 

0.00 

0.00 

0 

0.00 

[0.  Load] 

0.00 

Load 

SBO 

750.00 

0.00 

0 

0.00 

[0,  Transit] 

0.00 

Transit 

SBO 

750.00 

0.00 

0 

0.00 

[0.  SBO  to  SHO] 

0.00 

SBO  to  SHO 

SBO 

750.00 

0.00 

0 

0.00 

[0,  Start  Move] 

0.00 

Start  Move 

SBO 

750.00 
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Figure  82.  Hand  Simulation  Design  Point  6. 
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SimTime  Event  State  (S)  Cargo  (S) 

Damage  (D) 

Mission  Flag  (M)  Shore  Cargo  (SC)  [Next  Event] 

0.00 
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SHO 
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SHO  to  SBO 
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0.00 

[1 0,  Start  Move] 
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0.00 

[15,  End  Move;  15,  Exit  Range;  12,  Detect] 

12.00 

Detect 

SHO 
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0.00 
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0.00 

0 
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0.00 

[30,  End  Move;  30,  Exit  Range;  27,  Attack] 

27.00 

Attack 

SBO 

360.00 
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0.00 
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0.30 

0 

360.00 

[45,  End  Move;  45,  Exit  Range;  42,  Attack] 

42.00 

Attack 

SHO 
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Figure  83.  Hand  Simulation  Design  Point  7. 
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VII .  CAPABILITY  EVALUATION 


A  detailed  capabilities  hierarchy,  described  in  Chapter 
IV,  was  developed  to  explore  the  abilities  of  selected  M&S 
tools  used  at  the  NPS  and  in  the  DoD  to  model  the  potential 
SBE  Scenario.  Evaluation  of  those  M&S  tools,  listed  in 
Chapter  VI,  were  the  focus  of  the  created  functionality 
framework  that  was  used  for  M&S  modeling  and  implementation. 
The  purpose  of  this  chapter  is  to  present  results  of  the 
evaluation  conducted  on  six  M&S  tools:  JCATS,  MANA, 
Pythagoras,  NSS,  Simkit,  and  Arena.  The  specific  usability, 
flexibility,  and  scalability  of  the  models  were  examined 
separately  and  then  combined  for  a  full  comparison  of  the 
models  across  capabilities.  Figures  84  through  101  show  the 
complete  evaluation  of  all  M&S  tools. 

Interpretation  of  the  normalized  factor  in  the 
evaluation  of  models  was  subjective  based  on  the  structure 
of  the  capabilities  framework.  A  quartile  approach  was 
applied  to  associate  a  quick  reference  term  with  the 
determined  value.  Possible  values  for  normalized  factors 
range  from  zero  to  one,  where  threshold  points  for  the 
quartiles  were  designated  into  four  regions.  Table  21 
indicates  the  threshold  points  and  associated  labels,  where 
Very  High  represented  a  perfect  contribution  factor. 
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Quartile  Approach 


Value  Range 

Associate  Terms 

Definition 

0  to  0.25 

Low 

Contributes  less  than  a  quarter  of 

the  functionalities. 

0.26  to  0.50 

Medium 

Contributes  less  than  half  of  the 

functionalities . 

0.51  to  0.75 

High 

Contributes  greater  than  half  of 

the  functionalities. 

0.76  to  1.00 

Very  High 

Contributes  greater  than  three 

quarters  of  the  functionalities . 

Table  21.  Quartile  Approach  Listings. 

A.  JCATS  EVALUATION 

JCATS  was  evaluated  with  the  use  of  the  Jimenez  model 
where  Usability  and  Flexibility  were  High  and  Scalability 
was  Medium.  Table  22  shows  the  calculated  values  for  JCATS 
capabilities . 


Joint  Conflict  and  Tactical  Simulation  (JCATS) 


Capability 

Total 

Functionalities 

2(f) 

Roll  up 
Probability 

Normalized  (c) 

Usability 

53 

38 

0 . 72 

0 . 64 

Flexibility 

49 

34 

0.69 

0.62 

Scalability 

42 

22 

0.52 

0 .46 

Table  22.  JCATS  Capabilities  Evaluation. 
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1 .  Advantages 


The  first  advantage  of  JCATS  lied  within  the  Dynamic 
situations  that  the  M&S  tool  created  with  real-world  values 
and  physic  representation.  This  functionality  enabled 
direct  translation  of  results;  however,  it  also  increased 
run  times.  Secondly,  JCATS  was  one  of  two  simulations 
evaluated  that  utilized  securities  by  handling  classified 
databases.  Handling  classified  data  was  a  key  functionality 
DoD  M&S  tools  possess.  Lastly,  JCATS  was  one  of  two 
simulations  that  were  developed  to  be  used  in  combination 
with  other  M&S  tools  for  reusability,  which  allowed  for  the 
added  benefit  of  architectural  design  to  be  observed. 

2 .  D i s advan t age  s 

The  first  disadvantage  of  JCATS  was  implementation  of 
real-world  physics  in  the  T-craft  model  during  cargo 
transfer.  T-craft' s  waypoints  were  modeled  to  allow  for 
movement  near  the  shore  without  landing,  while  remaining  in 
sea  mode.  JCATS  imposed  shore  landing  conditions  into  the 
model  and  did  not  allow  for  T-craft  to  transit  to  the  shore 
when  the  waypoints  were  placed  on  the  shore  line.  Switching 
of  modes  from  sea  to  hover  consumed  time  during  simulation 
and  was  not  implemented  in  the  Jimenez  model.  The  second 
disadvantage  was  the  lack  of  supportabilities  provided  to 
users.  LT  Jimenez  had  the  benefit  of  hands  on  training  with 
JCATS  supported  by  the  System  Engineering  program 
leadership.  JCATS  complexity  did  not  lend  itself  to  novice 
computer  users  like  typical  decision  makers. 
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B.  MANA  EVALUATION 

MANA  was  evaluated  with  the  implementation  of  the  Basic 
and  Advanced  Scenarios  in  which  all  capabilities  were  rated 
as  High.  Table  23  shows  the  calculated  values  for  MANA 
capabilities . 


Map  Aware  Non-Uniform  Automata  (MANA) 

Capability 

Total 

Functionalities 

2(f) 

Roll  up 
Probability 

Normalized  (c) 

Usability 

53 

41 

0 .77 

0.57 

Flexibility 

49 

37 

0.76 

0.55 

Scalability 

42 

35 

0.83 

0.61 

Table  23.  MANA  Capabilities  Evaluation. 


1 .  Advantages 

The  first  advantage  of  MANA  was  the  ease  of 
implementation  with  MANA  interface  capabilities.  The  GUI 
applications  in  MANA  enabled  a  working  model  to  be  ready  for 
simulation  runs  without  the  need  to  debug  code.  The  user 
was  completely  separated  from  the  programming  level.  The 
second  advantage  was  the  numerous  parameter  settings 
available  for  manipulation  of  the  model  environment  that 
include  terrain  map  editor,  agent  attributes,  and  selectable 
complex  behavioral  actions.  The  overall  capability  of  MANA 
was  considered  High.  The  third  advantage  was  the  AABM  that 
facilitated  the  adjustability  of  agents  with  attributes  and 
triggers.  This  enabled  the  user  to  define  complex  actions 
and  decision  processes  that  were  not  commonly  found  in  M&S 
tools  like  DES. 
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2 .  D i s advan t age  s 


There  were  major  disadvantages  in  MANA  that  would 
prevent  its  widespread  use  in  DoD.  The  first  was  the  lack 
of  architectural  design.  MANA  was  not  HLA  compliant  nor 
open  sourced.  The  second  disadvantage  accompanied  the 
first,  where  MANA  did  not  conform  to  protocol  standards  or 
DoD  standards  in  terminology  and  representation  on  the 
battle  space.  MANA' s  disadvantages  were  noticeable  in  its 
evaluations,  nevertheless,  most  decision  makers  could  work 
past  these  issues  to  use  MANA  and  produce  quality  results. 

C .  PYTHAGORAS  EVALUATION 

Pythagoras  evaluation  yielded  all  capabilities  as  High. 
Table  24  shows  the  calculated  values  for  Pythagoras 
capabilities . 


Capability 

Total 

Functionalities 

Pythagorus 

E(f) 

Roll  up 
Probability 

Normalized  (c) 

Usability 

53 

37 

0.70 

0.56 

Flexibility 

49 

34 

0.69 

0.56 

Scalability 

42 

32 

0.76 

0.61 

Table  24.  Pythagoras  Capabilities  Evaluation. 

1 .  Advantages 

The  first  advantage  of  Pythagoras  was  the  robust 
selection  of  attributes  and  MOEs  that  greatly  surpassed  that 
of  MANA.  The  MOEs  were  not  available  to  be  defined  by  the 


179 


user  but  were  more  capable  in  measuring  parameters  in  the 
simulation  than  MANA  recorded  figures.  The  second  advantage 
was  the  GUI  that  was  implemented  gave  the  user  greater  range 
of  controls  on  agent  actions.  Weapons,  sensors,  and 
communication  controls  enabled  the  user  to  build  elements  of 
a  model  that  accounted  for  significant  amounts  of 
probability.  Pythagoras  also  introduced  a  "sideness" 
functionality  that  allowed  for  other  entities  to  be  created 
that  were  neutral,  which  added  to  dynamic  situations. 

2 .  D i s advan t age  s 

The  first  disadvantage  of  Pythagoras  was  that  the  large 
number  of  controls  available  to  be  adjusted  by  the  user. 
The  increased  number  of  attributes,  attitude  changers,  and 
movement  desires  often  made  the  dynamics  of  the  situation 
difficult  to  control  without  rigorous  implementation  plans. 
The  second  disadvantage  was  the  lack  of  physics  on  entities. 
The  bottom  up  approach  of  AABM  did  not  seem  to  focus  on  real 
physics  based  models,  but  merely  the  behavior  that  modeled 
the  individual  entity  actions.  Pythagoras  had  the  same 
disadvantages  of  MANA  with  reference  to  System  architecture 
and  interface  functionalities,  in  which  the  observed 
capabilities  contributions  were  High. 

D .  NSS  EVALUATION 

NSS  was  evaluated  with  the  implementation  of  the  Basic 
and  Advanced  Scenarios  where  all  capabilities  were  High. 
Table  25  shows  the  calculated  values  for  NSS  capabilities. 
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Naval  Simulation  System  (NSS) 


Capability 

Total 

Functionalities 

E(f) 

Roll  up 
Probability 

Normalized  (c) 

Usability 

53 

34 

0 . 64 

0.55 

Flexibility 

49 

33 

0.67 

0.57 

Scalability 

42 

30 

0 .71 

0.61 

Table  25 


NSS  Capabilities  Evaluation 


1 .  Advantages 

The  first  advantage  of  NSS  was  the  use  of  real  physics 
and  environmental  effects  on  entities  during  simulation  like 
sea  state  and  wind.  NSS  took  input  factors  and  applied 
physics  forces  during  run  time  similar  to  JCATS .  The  second 
advantage  was  that  the  discrete-based  processes  allowed  for 
more  accurate  results  than  time-step  models.  This  was 
observed  through  the  ability  to  select  confidence  interval 
values.  The  third  advantage  was  NSS  simulation  run  time 
durations  were  faster  than  those  of  JCATS  in  conducting 
multiple  replication  of  the  scenario.  NSS  simulation  runs 
were  conducted  over  hours,  where  JCATS  were  days  in 
duration.  The  last  advantage  was  that  NSS  allowed  for  near 
real  time  inputs  to  be  fed  into  the  model  for  course  of 
action  analysis. 

2 .  Disadvantages 

The  first  disadvantage  of  NSS  was  the  inability  of  a 
DES  to  not  model  waiting  queues  to  analysis  processes  in  a 
model.  The  major  advantage  of  the  two  following  M&S  tools 
was  waiting  queues  for  recorded  MOPs .  The  second 


disadvantage  was  resource  capabilities  that  did  not  allow 
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for  cargo  transfer  to  be  measured.  NSS  was  a  federation 
program,  but  was  not  open  source  or  HLA  compliant  in 
accordance  with  DoD  mandates.  The  last  disadvantage  was  the 
non  access  to  probability  tables  of  entities  imported  or 
copied  from  database  instances.  The  ability  to  create  a 
user  defined  entity  was  also  not  available. 

E .  SIMKIT  EVALUATION 

Simkit  was  evaluated  with  the  implementation  of  the 
Basic  and  Advanced  Scenarios  where  all  capabilities  were 
High.  Table  26  shows  the  calculated  values  for  Simkit 
capabilities . 


Capability 

Total 

Functionalities 

Simkit  DES 

E(f) 

Roll  up 
Probability 

Normalized  (c) 

Usability 

53 

25 

0 .47 

0 . 64 

Flexibility 

49 

19 

0.39 

0.53 

Scalability 

42 

17 

0.40 

0.55 

Table  26.  Simkit  Capabilities  Evaluation. 


1 .  Advantages 

The  first  advantage  of  Simkit  was  the  discrete  event 
processes  that  inherently  provided  highly  accurate 
simulation  results.  The  ability  of  the  user  to  define 
virtually  every  aspect  of  the  model  interactions  increased 
the  Usability  of  Simkit  with  a  0.64  factor.  The  second  was 
the  technical  support  provided  by  the  NPS  in  an  academic 
setting  that  could  be  made  available  to  decision  makers. 
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The  third  was  the  freedom  of  programming  to  define 
parameters  and  output  results  that  was  not  available  in  the 
other  M&S  tools. 

2 .  D i s advan t age  s 

The  first  disadvantage  of  Simkit  was  the  result  data 
were  highly  dependent  on  the  distributions  used  during 
simulations.  The  distributions  were  not  limited  by  the 
Simkit  API,  only  the  ability  of  the  user  to  create 
randomness  for  realistic  interactions.  The  second 
disadvantage  of  Simkit  was  the  lack  of  a  GUI  to  implement 
models.  This  swing  in  capabilities  between  user  interfaces 
made  differences  in  the  implementation  of  the  SBE  Scenarios 
but  were  leveled  out  in  the  evaluation  processes.  Simkit 
still  offered  High  capabilities  contributions. 

F.  ARENA  EVALUATION 

Arena  was  evaluated  with  the  implementation  of  the 
Basic  and  Advanced  Scenarios  where  the  Usability  capability 
was  Very  High  and  Flexibility  and  Scalability  capabilities 
were  Low.  Table  27  shows  the  calculated  values  for  Arena 
capabilities . 


Capability 

Total 

Functionalities 

Arena 

E(f) 

Roll  up 
Probability 

Normalized  (c) 

Usability 

53 

40 

0 .75 

0.92 

Flexibility 

49 

10 

0.20 

0.25 

Scalability 

42 

10 

0.24 

0.29 

Table  27.  Arena  Capabilities  Evaluation. 
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1 .  Advantages 


The  first  advantage  of  Arena  was  the  GUI  of  a  DES  that 
provided  Strong  Usability  of  the  M&S  tool.  This  enabled 
MOPs  to  represent  specific  processes  and  obtain  accurate 
results  with  confidence  intervals.  The  second  advantage  was 
the  ability  of  Arena  to  import  and  export  databases  for 
complex  simulations.  The  McDonald  model  allowed  for  an 
implementation  of  a  full  factorial  analysis  to  be  conducted 
with  varying  parameters  needed  to  determine  relationships. 
The  third  advantage  was  the  functionality  of  selectable 
units  in  the  model  that  allowed  for  rapid  MOP  translations. 

2 .  D i s advan t age  s 

The  GUI  of  Arena  was  a  highlight  in  its  abilities  due 
to  the  limitations  of  the  M&S  tool  to  model  Military 
operations  key  to  the  Advanced  Scenario.  The  first 
disadvantage  was  the  lack  of  visual  representation  of  a 
battle  space  in  which  the  T-craft  operated.  The  Arena 
processes  were  independent  of  location  and  based  on  a 
flowchart  method.  The  second  was  the  inability  for  entity 
interactions.  Entity  creation  was  limited  to  T-craft 
instances  where  escort  and  hostile  forces  could  not  be 
modeled.  Similar  to  other  M&S  tool  evaluated.  Arena  also 
was  poorly  designed  for  use  in  DoD  with  no  HLA  compliance  or 
reusability. 

G.  EVALUATION  SUMMARY 

The  evaluation  of  a  capability  hierarchy  framework  was 
an  extensive  compilation  of  six  models  created  in  six 
different  M&S  tools  used  in  DoD  and  academia.  The 
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evaluation  summary  is  shown  in  Table  28  and  compared  M&S 
tools  across  capabilities.  It  was  important  to  remember 
that  all  models  were  designed  for  a  specific  application  of 
real  situations  and  required  validation  in  those  areas. 


Capability 

JCATS 

Capability  Hierarchy  1 

MANA  Pythagorus 

Comparison 

NSS 

Simkit 

Arena 

Usability 

0.64 

0.57 

0.56 

0.55 

0 . 64 

0.92 

Flexibility 

0.62 

0.55 

0.56 

0.57 

0.53 

0.25 

Scalability 

0.46 

0.61 

0.61 

0.61 

0.55 

0.29 

Roll-up 

0.57 

0.58 

0.58 

0.58 

0.58 

0.49 

Table  28.  Capabilities  Evaluation  Summary. 


The  evaluation  of  the  M&S  tools  showed  similarities  and 
differences  in  their  capabilities.  Comparison  of  the 
evaluations  revealed  that  initial  assessments  of 
similarities  between  MANA  and  Pythagoras  held  true  with  High 
values  in  all  capabilities.  NSS  was  similar  to  MANA  and 
Pythagoras  despite  being  in  different  category  types  of  M&S. 
The  next  major  difference  was  found  in  the  Arena  evaluation 
where  its  Usability  showed  Very  High  values  but  Flexibility 
and  Scalability  had  Low  values.  This  was  no  surprise  based 
on  the  limitations  of  the  GUI  based  DES.  Simkit  and  JCATS 
held  similarities  in  Usability  but  differed  in  Scalability. 
JCATS  and  Arena  Low  values  for  Scalability  both  stemmed  from 
the  inability  to  allow  for  user  access  to  attain  abilities. 
Arena  is  the  odd  model  with  Low  values  for  Flexibility  and 
Scalability.  Thus,  the  M&S  user  had  multiple  options  that 
yielded  high  results.  In  the  next  chapter,  a  "suite  of 
simulations"  is  suggested  as  a  viable  option. 
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I  Joint  Conflict  and  Tactical  Simulation  (JCATS)  | 

Capability  Evaluation 

Cap  Charact  Ility  Trait 

Funct 

Functionality  Element 

Pts 

Eval 

Total 

Remarks 

USABILITY 

SUM 

0.72 

VALIDATION 

SUM 

0.49 

CONSTRUCTABILITIES 

SUM 

0.38 

1  DYNAMIC  SITUATIONS 

SUM 

0.25 

SENSOR 

PROB.  TABLES 

1 

1 

0.02 

Actual  Values 

WEAPON 

PROB.  TABLES 

1 

1 

0.02 

Actual  Values 

| INDIVIDUAL  UNIT  ACTIONS 

1 

1 

0.02 

Limited 

AGENT 

INFORMATION  (AI) 

1 

1 

0.02 

Limited 

AI  - 

COURSE 

1 

1 

0.02 

AI  - 

SPEED 

1 

1 

0.02 

AI  - 

POSITIONAL  DATA 

1 

1 

0.02 

AI  - 

REFUELING  RATES 

1 

1 

0.02 

AI  - 

CARGO  CAPACITIES 

1 

1 

0.02 

[COMMUNICATION  (CM) 

1 

1 

0.02 

Information  Exchange 

CM  - 

COMMAND  AND  CONTROL  ENTITY 

1 

0 

0.00 

Live  SIM  only 

CM  - 

MILITARY  OPERATIONS  other  than  WARFARE 

1 

1 

0.02 

Ground  Operations  only 

CM  - 

LOGISTIC  CAPABILITIES 

1 

1 

0.02 

WAITING  QUEUES 

1 

1 

0.02 

Supported  DES 

PERSONAL  SETTINGS 

1 

0 

0.00 

SEMI -AUTOMATED  FORCES 

1 

0 

0.00 

J  REPLICABLE 

SUM 

0.13 

SIMULATE  a  user  DEFINED  MODEL 

1 

1 

0.02 

MULTIPLE  RUNS  DEFINED  by  user 

1 

1 

0.02 

MEASURES  OF  PERFORMANCE 

1 

1 

0.02 

Not  User  Defined 

PARAMETERS 

1 

1 

0.02 

Selectable 

|  RESET 

SIMULATION  PARAMETERS 

1 

0 

0.00 

User  DEFINED  OUTPUT  VARIABLES 

1 

1 

0.02 

Selectable 

START/ STOP  CRITERIA 

1 

1 

0.02 

Only  Time 

ACCURACY 

1 

0 

0.00 

SPOT  SAMPLING 

1 

1 

0.02 

Playback  only 

SUPPORTABILITIES 

SUM 

0.11 

|  CONTRACTOR  SUPPORT 

SUM 

0.09 

BASIC 

INFORMAITON  (BI) 

1 

1 

0.02 

BI  - 

VERSION  NUMBER 

1 

1 

0.02 

Bi  - 

UPGRADE  INFORMATION 

1 

1 

0.02 

REACH-: 

BACK  AVAILABILITY 

1 

0 

0.00 

POINTS 

OF  CONTACTS  (PC) 

1 

0 

0.00 

PC  -  | 

| WEBSITE  AVAILABILITY 

1 

0 

0.00 

No  Active  URL 

TRAINING  and  EDUCATION 

1 

1 

0.02 

Limited 

FEEDBACK  LOOP 

1 

1 

0.02 

AUTHORITATIVE  SOURCES 

1 

0 

0.00 

j  DOCUMENTATION 

SUM 

0.02 

FUNCTIONALITY  TUTORIALS 

1 

0 

0.00 

HELP  WINDOWS 

1 

0 

0.00 

User  MANUAL 

1 

1 

0.02 

Fair 

PUBLICATIONS 

1 

0 

0.00 

|online 

SUPPORT 

1 

0 

0.00 

User  INTERFACE 

SUM 

0.23 

I  Representabilities 

SUM 

0.23 

J  Graphical  User  Interface  (GUI) 

SUM 

0.09 

|User  input  windows  (UI) 

1 

1 

0.02 

UI  - 

Pull  Down  Menus 

1 

1 

0.02 

UI  - 

Check  Boxes 

1 

1 

0.02 

UI  - 

Typed  in  Values 

1 

1 

0.02 

UI  - 

Adjustment  sliders 

1 

1 

0.02 

Set-up 

Wizards 

1 

0 

0.00 

j  Comprehensive 

i  able 

SUM 

0.13 

Pop-up 

Information 

1 

0 

0.00 

Common 

Terminology 

1 

1 

0.02 

Based  on  DoD  Instructions 

User  Feedback 

1 

1 

0.02 

Limited 

Help  Menus 

1 

1 

0.02 

Standard  Symbology  (SM) 

1 

1 

0.02 

Based  on  DoD  Instructions 

SM  - 

Friendly,  Hostile,  &  Neutral 

1 

1 

0.02 

Based  on  DoD  Instructions 

Forces 

1 

1 

0.02 

Object 

Templates 

1 

1 

0.02 

Figure  84.  JCATS  Usability  Evaluation  Sheet. 
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Joint  Conflict  and  Tactical  Simulation  (JCATS)  [ 

Capability  Evaluation 

Cap  Charact  Ility 

Trait 

Funct 

Functionality  Element 

Pts 

Eval 

Total 

Remarks 

Flexibility 

SUM 

0.69 

Modelable 

SUM 

0.53 

Securities 

SUM 

0.04 

J  Classification 

SUM 

0.04 

Safeguard  &  Handle  Classified  Information 

1 

1 

0.02 

Government  Certified 

Encryption  /  Decryption  Devices 

1 

1 

0.02 

I  Export 

/  Import  abilities 

SUM 

0.06 

j  Databases 

SUM 

0.06 

Systems  (Created  Models) 

1 

1 

0.02 

Environment  (Terrian  /  Weather  /  etc.) 

1 

1 

0.02 

Imagary  Data 

1 

0 

0.00 

Scenario  Files 

1 

1 

0.02 

Adjust 

abilities 

SUM 

0.43 

J  Systems 

SUM 

0.22 

|Multiple  Attributes 

1 

1 

0.02 

Poor 

| Model  : 

Basic  Physics 

1 

1 

0.02 

Excellent 

Refueling  Capabilities 

1 

1 

0.02 

Movement  Parameters 

1 

1 

0.02 

Indirect  Application 

Mode  Selection 

1 

0 

0.00 

|Clone 

/  Copy  Functions 

1 

1 

0.02 

Standard  Copy 

|Military  Operations  (MO) 

1 

0 

0.00 

MO  - 

Guard 

1 

0 

0.00 

MO  - 

Patrol 

1 

0 

0.00 

MO  - 

Orbit 

1 

0 

0.00 

MO  - 

Attack 

1 

1 

0.02 

Standard 

MO  - 

Flee  /  Run 

1 

1 

0.02 

MO  - 

Grouping  Functions 

1 

1 

0.02 

C2  Hierarchy 

MO  - 

Inter  Communications 

1 

0 

0.00 

MO  - 

Remain  in  place 

1 

1 

0.02 

MO  - 

Waypoint  selection 

1 

1 

0.02 

Mandatory 

MO  - 

Unit  operations 

1 

1 

0.02 

C2  Hierarchy 

J  Environment 

SUM 

0.14 

1 2D  Terrain  Modeling  (2D) 

1 

1 

0.02 

Limited 

2D  - 

Surface  Configuration 

1 

1 

0.02 

2D  - 

Natural  Features 

1 

0 

0.00 

2D  - 

Man-made  Features 

1 

0 

0.00 

|Oceanographic  Modeling  (OM) 

1 

1 

0.02 

Limited 

|0M  -  | 

|Contours  with  depth  data 

1 

1 

0.02 

| External  Forces  (EF) 

1 

1 

0.02 

EF  - 

Wind 

1 

1 

0.02 

EF  - 

Sea  State 

1 

1 

0.02 

|  Measures  of  Performance 

SUM 

0.04 

Survivability 

1 

1 

0.02 

Transit  Times 

1 

1 

0.02 

|  Cargo  ' 

Transfer 

1 

0 

0.00 

|  Resolution 

SUM 

0.02 

|T-craft  Levels  (Single  vs.  Multiple) 

1  i 

|  Architectural 

.  Design 

SUM 

0.12 

j  | Interoperability  Standards  &  Protocol 

1  i 

I  0.02 

1 

|  Federate  Capable 

SUM 

0.06 

High  Level  Architecture  (HLA)  Capable 

1 

1 

0.02 

Reusable  Program 

1 

1 

0.02 

Program  History 

1 

1 

0.02 

Program  Considerations 

SUM 

0.04 

[open- Source  Code 

1 

0 

0.00 

Input  ' 

Operational  Data  (10) 

1 

1 

0.02 

Operational  User 

10  -  j 

|0bject  Library 

1 

1 

0.02 

Main  Database 

|Auto  Save  /  Auto  Recover 

1 

0 

0.00 

Stochastic  Process 

SUM 

0.04 

|Scriptable  |  ) 

1 

1 

0.02 

|  Discrete-Event 

1 

0 

0.00 

|  Random 

Variables /Markov  Principles 

1 

0 

0.00 

j  |Time_Step 

1 

1 

1 

0.02 

_ 

|  Random 

Variables /Markov  Principles 

1 

0 

0.00 

Figure  85.  JCATS  Flexibility  Evaluation  Sheet. 
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Joint  Conflict  and  Tactical  Simulation  (JCATS)  I 

Capability  Evaluation 

Cap  Charact  Ility  Trait 

Funct 

Functionality  Element 

Pts 

Eval 

Total 

Remarks 

Scalability 

SUM 

0.52 

Variation 

SUM 

0.52 

Adjust  abilities 

SUM 

0.45 

Systems 

SUM 

0.26 

|Multiple  Attributes 

1 

1 

0.02 

Poor 

| Model  : 

Basic  Physics 

1 

1 

0.02 

Excellent 

Refueling  Capabilities 

1 

1 

0.02 

Movement  Parameters 

1 

1 

0.02 

Indirect  Application 

Mode  Selection 

1 

0 

0.00 

|Clone 

/  Copy  Functions 

1 

1 

0.02 

Standard  Copy 

|Military  Operations  (MO) 

1 

0 

0.00 

MO  - 

Guard 

1 

0 

0.00 

MO  - 

Patrol 

1 

0 

0.00 

MO  - 

Orbit 

1 

0 

0.00 

MO  - 

Attack 

1 

1 

0.02 

Standard 

MO  - 

Flee  /  Run 

1 

1 

0.02 

MO  - 

Grouping  Functions 

1 

1 

0.02 

C2  Hierarchy 

MO  - 

Inter  Communications 

1 

0 

0.00 

MO  - 

Remain  in  place 

1 

1 

0.02 

MO  - 

Waypoint  selection 

1 

1 

0.02 

Mandatory 

MO  - 

Unit  operations 

1 

1 

0.02 

C2  Hierarchy 

|  Environment 

SUM 

0.12 

1 2D  Terrain  Modeling  (2D) 

1 

1 

0.02 

Limited 

2D  - 

Surface  Configuration 

1 

0 

0.00 

2D  - 

Natural  Features 

1 

0 

0.00 

2D  - 

Man-made  Features 

1 

0 
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Figure  86.  JCATS  Scalability  Evaluation  Sheet. 
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Figure  87.  MANA  Usability  Evaluation  Sheet. 
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Figure  88.  MANA  Flexibility  Evaluation  Sheet. 
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Figure  89.  MANA  Scalability  Evaluation  Sheet. 
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Figure  90.  Pythagoras  Usability  Evaluation  Sheet. 
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Figure  91.  Pythagoras  Flexibility  Evaluation  Sheet. 
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Figure  92.  Pythagoras  Scalability  Evaluation  Sheet. 
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Figure  93.  NSS  Usability  Evaluation  Sheet. 
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Figure  94.  NSS  Flexibility  Evaluation  Sheet. 
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Figure  95.  NSS  Scalability  Evaluation  Sheet. 
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Figure  96.  Simkit  Usability  Evaluation  Sheet. 
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Figure  97.  Simkit  Flexibility  Evaluation  Sheet. 
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Figure  98.  Simkit  Scalability  Evaluation  Sheet. 
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Figure  99.  Arena  Usability  Evaluation  Sheet. 
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Figure  100.  Arena  Flexibility  Evaluation  Sheet. 


202 


Arena 

Capability  Evaluation 

Cap  Charact  Ility  Trait 

Funct 

Functionality  Element 

Pts 

Eval 

Total 

Remarks  | 

Scalability 

SUM 

0.24 

Variation 

SUM 

0.24 

Adjust  abilities 

SUM 

0.12 

Systems 

SUM 

0.02 

|Multiple  Attributes 

1 

0 

0.00 

|Model  : 

Basic  Physics 

1 

0 

0.00 

Refueling  Capabilities 

1 

1 

0.02 

Movement  Parameters 

1 

0 

0.00 

Mode  Selection 

1 

0 

0.00 

|Clone 

/  Copy  Functions 

1 

0 

0.00 

|Military  Operations  (MO) 

1 

0 

0.00 

MO  - 

Guard 

1 

0 

0.00 

MO  - 

Patrol 

1 

0 

0.00 

MO  - 

Orbit 

1 

0 

0.00 

MO  - 

Attack 

1 

0 

0.00 

MO  - 

Flee  /  Run 

1 

0 

0.00 

MO  - 

Grouping  Functions 

1 

0 

0.00 

MO  - 

Inter  Communications 

1 

0 

0.00 

MO  - 

Remain  in  place 

1 

0 

0.00 

MO  - 

Waypoint  selection 

1 

0 

0.00 

MO  - 

Unit  operations 

1 

0 

0.00 

Environment 

SUM 

0.00  | 

1 2 D  Terrain  Modeling  (2D) 

1 

0 

0.00 

2D  - 

Surface  Configuration 

1 

0 

0.00 

2D  - 

Natural  Features 

1 

0 

0.00 

2D  - 

Man-made  Features 

1 

0 

0.00 

|Oceanographic  Modeling  (OM) 

1 

0 

0.00 

|OM  -  | 

| Contours  with  depth  data 

1 

0 

0.00 

|External  Forces  (EF) 

1 

0 

0.00 

EF  - 

Wind 

1 

0 

0.00 

EF  - 

Sea  State 

1 

0 

0.00 

Measures  of  Performance 

SUM 

0.07  f 

Survivability 

1 

1 

0.02 

Excellent  Processes 

Transit  Times 

1 

1 

0.02 

Excellent  Processes 

|Cargo  ' 

Transfer 

1 

1 

0.02 

Excellent  Processes 

Resolution 

SUM 

0.02  1 

|  |T-craft  Levels  (Single  vs.  Multiple) 

1  i 

1  1  1 

|  Sinlge  Entity  Replicated  j 

Adjudication 

SUM 

0.12 

Attain 

abilities 

SUM 

0.12 

|Results  (RS) 

1 

1 

0.02 

RS  - 

Units  of  Measure 

1 

1 

0.02 

Time  units 

RS  - 

MOP's  Translations 

1 

1 

0.02 

RS  - 

User  Defined  Data  Output 

1 

1 

0.02 

RS  - 

Battle  Damage  Assessments 

1 

0 

0.00 

|Engagement  (EG) 

1 

0 

0.00 

EG  - 

Probability  Tables  Ph/Pk 

1 

1 

0.02 

Imported  Databases 

EG  - 

Sensor  Algorithms  Integration 

1 

0 

0.00 

EG  - 

Weapons  Algorithms  Integration 

1 

0 

0.00 

EG  - 

Indirect  Fire  Capabilities 

1 

0 

0.00 

EG  - 

Sensor  Detections 

1 

0 

0.00 

EG  - 

Battle  Damage 

1 

0 

0.00 

Figure  101.  Arena  Scalability  Evaluation  Sheet. 
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VIII . 


SIMULATION  COMPARISON 


Evaluation  across  M&S  categories  revealed  similarities 
and  differences  among  the  M&S  tools.  These  comparisons  are 
generalized  in  this  chapter  to  understand  capabilities  that 
were  determined  to  be  present.  Select  capabilities  of  the 
M&S  tools  used  gave  way  to  a  combination  of  functionalities 
that  may  be  used  in  future  M&S  development.  The  use  of  an 
M&S  tool  or  a  suite  of  M&S  tools  is  introduced  in  this 
chapter  for  SBE  modeling  that  could  be  expanded  to  other 
areas  of  research  and  development.  A  "suite  of  simulation" 
concept  was  discussed,  due  to  the  fact  that  the  validation 
of  a  single  M&S  tool  was,  by  definition,  narrowed  for  a 
specific  use.  For  example,  what  if  a  series  of  M&S  tools 
linked  or  integrated  together  to  utilize  their  complementary 
functionalities?  The  pros  and  cons  of  this  idea  are 
discussed.  The  last  idea  presented  in  this  chapter  is  the 
trade  space  of  M&S  tools  analyzed  in  this  study  and  their 
limitations  in  a  "suite  of  simulations." 

A.  OBSERVED  CAPABILITIES 

The  two  main  types  of  simulations  evaluated  were  time- 
step  and  next-event  based  models.  These  models  displayed 
opposite  strengths  in  capabilities  of  modeling  a  SBE 
Scenario.  Time-step  simulations  scored  High  Scalability  for 
scenario  representation  and  attainability.  The  general 
functionalities  displayed  were  agent  actions  and  visual 
representation  of  the  SBE  Scenario.  In  models  like  MANA  and 
Pythagoras,  the  ability  of  the  user  to  define  agent  actions 
exceeded  the  actions  of  entities  in  next-event  models.  AABM 
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enabled  controls  for  attained  abilities  that  were 
specifically  design  to  model  the  individual  unit's  decision 
making  process  remain  an  aspect  of  time-step  based  models. 
Next-event  simulations  scored  High  Usability  for  scenario 
validation  and  user  interface.  The  functionalities  derived 
from  next-event  based  models  were  the  implementation  of 
physics  based  models  and  user  interface  options  across  M&S 
tools.  Next-event  based  models''  key  capabilities  modeled 
real  systems  in  simulation  environments  to  test  and  measure 
performance  in  dynamic  situations.  The  validation  of  the 
M&S  tools  was  critical  to  the  outcomes  of  simulation. 
Interface  characteristics  were  observed  in  next-event 
models,  in  which  the  ability  to  model  a  wide  range  of 
processes  showed  High  Usability  contributions. 

There  were  associations  within  and  across  simulation 
types  that  were  observed  in  the  M&S  tools  used  in  this 
research.  JCATS  and  NSS  are  both  military-type  simulations 
that  modeled  real  physical  entity  interactions. 
Similarities  of  JCATS  and  NSS  included  (1)  Environment 
representation  that  affected  T-craft  object  motion  and 
interactions,  (2)  Databases  containing  platform  modeled 
objects  that  possessed  real-world  parameter  inputs,  (3) 
Federation  of  the  M&S  tools  program  to  be  reused  and 
integrated  with  other  source  code,  and  (4)  Securities  to 
handle  classified  materials.  Evaluation  of  MANA  and 
Pythagoras  capabilities  revealed  that  there  were  similar  GUI 
functionalities,  which  were  attribute  controls  and 
replication  abilities. 

Unexpectedly  there  was  not  the  same  level  of 
correspondence  between  the  next-event  based  models.  NSS 
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differed  from  Simkit,  which  in  turned  differed  from  Arena. 
NSS  and  Arena  shared  similar  functionalities  like  GUIs,  yet 
showed  differences  in  replication  abilities  and  support 
systems.  Simkit  and  Arena  were  both  DES  but  differed  in 
implementation  of  the  interfaces.  Simkit  had  High 
Flexibility  and  Scalability  due  to  the  MOP  capabilities 
observed  and  optimized  processes.  Arena  had  Strong 
Usability  with  GUI,  support  functionalities,  and  replication 
applications.  The  three  next-event  models  were  as  distinct 
as  they  were  similar. 

B.  SIMULATION  SUITES 

The  evaluation  of  the  M&S  tools  in  this  research  led  to 
the  guestion  of  which  one  or  combination  of  simulations  were 
capable  of  modeling  a  SBE  Scenario.  Combination  of 
simulation  was  defined  as  a  suite  of  integrated  M&S  tools. 
Beginning  with  the  base  model  trade  space,  all  possible 
"suites  of  simulations"  would  lie  within  the  constructive 
model  trade  space  as  discussed  in  Chapter  III.  Based  on  the 
observed  evaluation  of  the  six  models,  the  models  with  the 
highest  Usability  were  Simkit  and  JCATS  with  0.64,  High 
contribution  to  the  functionalities.  Simkit'’ s  overall 
processes  in  Flexibility  and  Scalability  were  observed  as 
High,  which  made  an  ideal  candidate  for  SBE  Scenario 
processing  M&S  tool.  The  models  with  a  High  Flexibility  and 
Scalability  were  MANA  and  Pythagoras.  These  observed 
capabilities  used  in  conjunction  with  DES  surrounding  the 
next-event  based  models  as  depicted  in  Figure  102,  provided 
a  possible  solution  trade  space  for  SBE  modeling. 
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Figure  102  illustrates  the  M&S  space  that  a  simulation 
or  "suite  of  simulations"  should  be  in  for  SBE  Scenario 
modeling.  The  general  idea  behind  the  M&S  trade  space  was 
to  integrate  the  processing  capabilities  of  DES  with  time- 
step  based  models  to  provide  functionalities  to  flexible  and 
scalable  M&S  tools.  The  limitation  to  this  idea  is  the 
coupling  of  AABM  with  DES.  Current  AABM  are  not  capable  of 
introducing  next-event  based  processes  in  the  logic  and/or 
source  code.  A  possible  "suite  of  simulations"  is  modeling 
cargo  transfer  processes  in  Simkit  and  transit  interactions 
in  MANA  to  solve  for  all  MOPs .  This  would  allow  for  the  M&S 
space  to  encompass  both  types  of  simulations. 
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C .  TRADE  SPACE 

There  are  options  being  developed  at  the  NPS  to 
increase  the  capability  of  Simkit  and  DES.  The  Viskit 
simulation  is  an  open  source  simulation  code  that  attempts 
to  marry  the  processing  power  of  a  DES  with  the  usability  of 
a  GUI  program.  Viskit  implements  Java  programming  for  use 
by  non  programmers.  Viskit  is  a  rapid  development  M&S  tool 
that  is  based  on  reusable  components  of  the  Simkit  API 
(Buss,  2008) .  Viskit  could  be  considered  to  provide  the 
needed  user  interface  that  Simkit  lacks.  Arena  can  not  be 
in  the  same  discrete  event  space  as  Simkit  because  of  the 
flowchart  based  model  used.  Arena  is  a  next-event  model  but 
does  not  implement  event  graph  properties  that  Simkit  uses 
to  create  separate  object  entities. 

Based  on  Chapter  VII  results,  there  was  another  option 
in  the  trade  space  for  a  "suite  of  simulations"  for  SBE 
modeling.  Simkit  and  NSS  displayed  similar  capabilities  in 
the  evaluation.  The  possibility  of  NSS  replacing  Simkit  in 
the  "suite  of  simulation"  space  is  worth  exploring.  NSS  is 
a  next-event  based  model  with  equivalent  contributions  to 
their  capabilities.  NSS  additionally  offers  database 
functionality,  in  conjunction  with  the  Simkit  API  may  prove 
to  be  a  powerful  M&S  tool.  The  trade  space  illustrates  that 
the  possibility  for  using  M&S  tools  in  series  or  tandem  may 
provide  decision  makers  with  a  product  that  has  Very  High 
capabilities  for  analysis  and  use. 
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IX.  CONCLUSION 


The  goal  of  the  hierarchy  framework  was  to  define  the 
M&S  capabilities  of  a  SeaBase  Enabler  (SBE)  in  a  set  of 
functionalities  for  evaluating  simulations.  The  framework 
was  generated  to  enable  the  application  of  a  systematic 
process  to  be  applied  to  any  system  to  determine  the 
capabilities  and  put  a  numeric  value  on  the  abilities 
relative  to  the  total  number  of  individual  functionalities 
of  the  system.  The  results  of  the  evaluations  were  then 
used  to  determine  a  suitable  simulation  or  a  "suite  of 
simulations"  for  SBE  modeling. 

There  were  six  similar  SBE  models  that  were  created  in 
six  different  M&S  tools.  The  six  simple  models  merely 
provided  a  method  for  evaluating  the  capabilities  of  the 
simulations  and  to  prove  the  framework  was  viable.  Valuable 
insight  was  gained  by  scenario  development  of  the  basic 
models  used.  The  intent  of  providing  detailed  modeling 
parameters  was  to  enable  future  analysis  in  SBE  modeling 
with  models  that  are  executable. 

The  SBE  concept  is  unique  to  military  operations 
because  of  the  potential  logistical  support  by  a  transport 
craft  that  has  not  been  offered  in  the  past.  The  use  of  M&S 
in  the  development  of  a  SBE  like  T-craft  can  provide  insight 
into  the  advantages  of  large  cargo  capacities  and  increased 
speed  capabilities.  The  scenarios  created  in  this  study 
were  designed  to  specifically  measure  T-craft  performance 
parameters  and  determine  what  could  be  modeled  in  the  two 
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different  types  of  simulation.  The  construction  of  a  T- 
craft  scenario  in  M&S  tools  allowed  for  comparison  of 
capabilities  across  M&S  Domains. 

All  simulation  types  seem  to  have  components  that  are 
interchangeable  with  each  other.  This  integration  can  blur 
the  distinctions  between  the  two  categories  depicted  here. 
However,  use  of  specific  simulations  in  this  study,  there 
were  comparisons  within  and  across  the  categories.  The  goal 
was  to  define  the  capabilities  of  a  simulation  for  a  SBE  and 
provide  a  baseline  for  simulations  that  decision  makers 
would  want  to  conduct  independent  analysis  to  awareness. 
The  battle  over  money  for  acquisition  of  systems  has  become 
overwhelming.  Any  assistance  that  can  be  provided  by  the 
ease  of  M&S  tools  will  give  options  to  DoD  employees. 

The  framework  created  has  shown  that  an  evaluation  of 
simulations  can  be  conducted.  The  bulk  of  the  work 
conducted  in  this  thesis  was  focused  on  the  definition  of 
the  capability  hierarchy.  The  initial  assumption  was  that 
there  would  be  an  objective  core  to  the  framework  to  enable 
the  measurement  of  capabilities  for  a  given  simulation. 
This  was  done  by  the  presence  or  non  presence  of 
functionalities.  Use  of  the  roll-up  method  allowed  for  the 
contribution  of  any  functionality  to  be  calculated. 

The  capability  hierarchy  was  initially  developed  from 
the  desired  capabilities  of  a  SBE  but  evolved  with  the 
research  to  incorporate  other  M&S  requirements.  End  users' 
(Stakeholders)  needs  were  the  driving  force  behind  the  list 
of  capabilities  for  a  SBE.  Based  on  the  combination  of  end 
user  needs  and  DoD  capability  requirements  for  M&S  tools, 
the  creation  of  the  capability  hierarchy  allowed  for  a  wide 
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range  of  operations  to  be  modeled  in  a  SBO  Scenario.  Model 
development  seems  to  have  led  to  additions  in  all  areas  of 
capabilities.  The  process  of  creating  a  framework  for  other 
systems  may  take  extensive  exploration  in  the  solution  trade 
space . 

Finally,  this  framework  demonstrated  that  objective 
comparison  of  simulations  capabilities  that  could  be  made 
with  what  first  seems  to  be  a  subjective  approach.  The 
question  of  how  capable  is  a  simulation  at  first  glance,  is 
not  objective.  This  thesis  attempted  to  objectively  show 
that  with  the  use  of  a  roll-up  method,  an  subjective  or 
quantitative  comparison  could  be  made  of  individual  M&S 
tools,  along  with  comparison  across  multiple  simulations 
category  types.  The  end  results  of  the  comparison  showed 
that  a  "suite  of  simulations"  could  be  more  capable  of 
modeling  a  SBE  Scenario  than  a  single  simulation,  but  shows 
that  specific  individual  simulations  have  been  created  with 
a  combination  of  the  more  capable  elements  of  the  M&S  tools 
evaluated . 
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APPENDIX  A.  CAPABILITY  HIERARCHY 


Usability 


Validation 

Construct  abilities 
Dynamic  Situations 

Sensor  Probability  Tables 
Weapons  Probability  Tables 
Individual  Unit  actions 
Agent  Information 
-Course 
-Speed 

-Positional  Data 
-Refueling  Rates 
-Cargo  Capacities 
Communications 

-Command  and  Control  Entity 
-Operation  other  than  Warfare 
-Logistic  Capabilities 
Waiting  Queues 
Personal  Settings 
Semi -Automated  Forces 
Replicable 

Simulate  a  user  defined  model 
Multiple  Runs  defined  by  user 
Measure  of  Performance 
Parameters 

Reset  Simulation  Parameters 
User  Define  output  variables 
Start/Stop  Criteria 
Accuracy 
Spot  Sampling 
Supportabilities 
Contractor  Support 
Basic  Information 
-Version  Number 
-Upgrade  information 
Reach-back  Availability 
Points  of  Contact 
-Web  Site  Availability 
Training  &  Education 
Feedback  Loop 
Authoritative  Sources 
Documentation 

Functionality  Tutorials 
Help  Windows 
User  Manual 
Publications 
On-line  Support 
User  Interface 
Represent  abilities 
Graphical  User  Interface  (GUI) 
User  input  windows 


215 


-Pull  Down  Menus 
-Check  Boxes 
-Typed  in  Values 
-Adjustment  sliders 
Set-up  Wizards 
Comprehensive  able 
Pop-up  Information 
Common  Terminology 
User  Feedback 
Help  Menus 
Standard  Symbology 
-Friendly,  Hostile,  &  Neutral 
Forces 

Object  Templates 
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Flexibility 


Model  able 
Securi ties 
Classification 

Safeguard  &  Handle  Classified 
Information 

Encryption  /  Decryption  Devices 
Export  /  Import  abilities 
Databases 

Systems  (Created  Models) 

Environment  (Terrain  /  Weather  /  etc.) 
Imagery  Data 
Scenario  Files 
Adjust  abilities 
Systems 

Multiple  Attributes 
Model  Basic  Physics 
Refueling  Capabilities 
Movement  Parameters 
Mode  Selection 
Clone  /  Copy  Functions 
Military  Operations 
-Guard 
-Patrol 
-Orbit 
-Attack 
-Flee  /  Run 
-Grouping  Functions 
-Inter  Communications 
-Remain  in  place 
-Waypoint  selection 
-Unit  operations 
Environment 

2D  Terrain  Model 
-Surface  Configuration 
-Natural  Features 
-Man-made  Features 
Oceanographic  Modeling 
-Contours  with  depth  data 
External  Forces 
-Wind 

-Sea  State 

Measures  of  Performance 
Survivability 
Transit  Times 
Cargo  Transfer 
Resolution 

T-craft  Levels  (Single  vs.  Multiple) 
Architectural  Design 

Interoperability  Standards  &  Protocol 
Federate  Capable 
High  Level  Architecture  (HLA) 

Capable 

Reusable  Program 
Program  History 


217 


Program  Considerations 
Open  Source  Code 
Input  Operational  Data 
-Object  Library 
Auto  Save  /  Auto  Recover 
Stochastic  Process 
Scriptable 

Discrete -Event /Time- Step 

Random  Variables/Markov  Principles 
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Scalability 


Variation 

Adjust  abilities 
Systems 

Multiple  Attributes 
Model  Basic  Physics 
Refueling  Capabilities 
Movement  Parameters 
Mode  Selection 
Clone  /  Copy  Functions 
Military  Operations 
-Guard 
-Patrol 
-Orbit 
-Attack 
-Flee  /  Run 
-Defend 

-Grouping  Functions 
-Inter  Communications 
-Remain  in  place 
-Waypoint  selection 
-Unit  operations 
Environment 

2D  Terrain  Modeling 

-Surface  Configuration 
-Natural  Features 
-Man-made  Features 
Oceanographic  Modeling 
-Contours  with  depth  data 
External  Forces 
-Wind 

-Sea  State 

Measures  of  Performance 
Survivability 
Transit  Times 
Cargo  Transfer 
Resolution 
Force  Levels 

T-craft  Levels  (Single  vs.  Multiple) 
Adjudication 
Attain  abilities 
Results 

Units  of  Measure 
MOP  Translations 
User  Defined  Data  Output 
Battle  Damage  Assessments 
Engagement 

Probability  Tables  Ph/Pk 
Sensor  Algorithms  Integration 
Weapons  Algorithms  Integration 
Indirect  Fire  Capabilities 
Sensor  Detections 
Battle  Damage 
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APPENDIX  B.  SIMKIT  SOURCE  CODE  FOR  SBE  SCENARIO 


/** 

*  SBE  Scenario 

*  Simkit  API  Source  code  in  Java  2  Platform  Standard  Ed.  5.0 

*  Authors:  LT  Ryan  Hernandez 

*  LtCOL  (HEA)  Sotiris  Papadopoulos 

*  Date:  May  2010 

*  MainProgram  Class 
*/ 


package  TCraftSourceCode; 


import 

import 

import 

import 

import 

import 

import 

import 

import 

import 

import 

import 

import 

import 

import 

import 

import 

import 

import 

import 


j  ava . awt . geom. Point2D; 

j  ava . beans . Proper tyChangeListener ; 

j  ava . io . Buf feredWriter ; 

j  ava . io . FileNotFoundException; 

j  ava . io . FileWriter ; 

j  ava . io . IOException; 

j  ava . lang . reflect .Array; 

j  ava .util . ArrayList; 

j  ava . util . LinkedList; 

simkit . random. RandomVariate; 

simkit . random. RandomVariateFactory; 

simkit . smd . BasicLinearMover ; 

simkit . smd . Basic Sensor; 

simkit . smd . Coo kieCut ter Sensor; 

simkit . smd . RandomMoverManager; 

simkit . smd. SensorMoverReferee; 

simkit . smdx . WayPoint; 

simkit . stat . SimpleStatsTimeVarying; 

simkit . Schedule; 

simkit . util . SimplePropertyDumper ; 


public  class  MainProgram  { 

/** 

*  @param  Main  program  execution  file 
*/ 

public  static  void  main ( String [ ]  args)  { 


//Friendly  force  setup  with  speed  set  to  40 
TCraft  friend  =  new  TCraft ( "TCraft, "  40.0); 


/* 

*  Friendly  way  point  inputs 

*  TCraft  starts  @  Debarkation  point  (DBK)  and  is  loaded. 

*  TCraft  transits  to  SeaBase  Operations  (SBO)  area  to  check  damage 
and  cargo  load. 

*  TCraft  then  transits  to  Shore  landing  site  (SHO)  to  unload  cargo. 

*  TCraft  completes  Shore  Cargo  requirements  and  returns  to  DBK. 

* 

*  DBK  =>  SBO  =>  SHO  ===>  Complete  cargo  tranfer  requirements  =>  DBK 
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/ 


LinkedList<WayPoint>  wayPointList  =  new  LinkedList<WayPoint> ( )  ; 

//Adds  waypoints  to  link  list  for  Mover  Manager  inputs  at  start  time 

wayPointList . add (TCraft . DBK)  ; 

wayPointList . add (TCraft . SBO)  ; 

wayPointList . add (TCraft . SHO)  ; 

wayPointList . add (TCraft . SBO) ; 

wayPointList . add (TCraft . SHO) ; 

wayPointList . add (TCraft . SBO)  ; 

wayPointList . add (TCraft . SHO)  ; 

wayPointList . add (TCraft . SBO)  ; 

wayPointList . add (TCraft . DBK) ; 

TCraf tMoverManager  friendMM  =  new  TCraf tMoverManager ( friend, 
wayPointList,  true) ; 

//Adding  listeners 

friend . addSimEvent Listener (friendMM) ; 
friendMM. addSimEventListener (friend) ; 

/ /Enemy  force  setup 

BasicLinearMover  enemy  =  new  BasicLinearMover ( "Enemy, "  new 
Point2D . Double ( 5 . 0 ,  10.0),  10.0); 

RandomVariate [ ]  rv  =  new  RandomVariate [2 ] ; 

rv[0]  =  RandomVariateFactory . getlnstance ( "Uniform, "  -20.0,  20.0) 
rv [ 1 ]  =  RandomVariateFactory . getlnstance ( "Normal , "  0.0,  5.0); 

RandomMoverManager  randomMoverManager  =  new  RandomMoverManager (enemy 
rv,  true) ; 

BasicSensor  enemyEye  =  new  CookieCutterSensor (enemy,  10.0); 

//Sea  base  setup 

BasicLinearMover  seabase  =  new  BasicLinearMover ( "Seabase, "  new 
Point2D . Double ( 0 . 0 ,  0.0),  0.0); 

BasicSensor  seabaseEye  =  new  CookieCutterSensor (seabase,  15.0); 

//Print  of  objects  in  simulation  to  check  initialization 
/ / System. out.println (friend)  ; 

/ / System. out .println (friendMM)  ; 

/ / System. out .println (enemy) ; 

/ / System. out .println (randomMoverManager) ; 

/ / System. out .println (enemyEye) ; 

/ / System. out.println (seabase)  ; 

/ / System. out .println (seabaseEye)  ; 

//Referee  setup 

SensorMoverReferee  referee  =  new  SensorMoverReferee ( ) ; 

friend. addSimEventListener (referee)  ; 

friendMM. addSimEventListener (referee) ; 

enemy. addSimEventListener (referee)  ; 

enemyEye . addSimEventListener (referee)  ; 

seabase . addSimEventListener (referee)  ; 

seabaseEye . addSimEventListener (referee) ; 
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//Mediator  setup 

TCraf tMediator  tCraf tMediator  =  new  TCraf tMediator () ; 
referee . addMediator (CookieCutterSensor .class ,  TCraf t .class , 
tCraf tMediator ) ; 

//Sensor  setup 

HostileSensor  hostileSensor  =  new  HostileSensor () ; 
enemyEye . addSimEventListener (hostileSensor) ; 

//Adjudicator  setup 

Adjudicator  adjudicator  =  new  Adjudicator () ; 

hostileSensor. addSimEventListener (adj udicator )  ; 

//Property  dumper  setup 

//SimplePropertyDumper  simplePropertyDumper  =  new 
SimplePropertyDumper ( ) ; 

/ / friend . addPropertyChangeListener (simplePropertyDumper) ; 

//Statistic  listener  setup 
PropertyChangeListener  cargoAmount  =  new 
SimpleStatsTimeVarying ( "cargo" ) ; 
friend. addPropertyChangeListener (cargoAmount) ; 
PropertyChangeListener  damageAmount  =  new 
SimpleStatsTimeVarying ( "damage" ) ; 
friend. addPropertyChangeListener (damageAmount) ; 
PropertyChangeListener  shoreCargoAmount  =  new 
SimpleStatsTimeVarying ( "shoreCargo" )  ; 
friend. addPropertyChangeListener (shoreCargoAmount) ; 
PropertyChangeListener  surv  =  new 

SimpleStatsTimeVarying ( "survivability" ) ; 
friend . addPropertyChangeListener ( surv) ; 

PropertyChangeListener  msnFlag  =  new 

SimpleStatsTimeVarying ( "missionFlag" ) ; 
friend . addPropertyChangeListener (msnFlag) ; 

//Simulation  initial  scheduling  commands 
Schedule . setEventSourceVerbose (true)  ; 

Schedule . stopAtTime (50.0)  ; 

Schedule . setVerbose (false)  ; 

//sets  the  number  of  iterations/replications  the  simulation  will 
conduct 

int  iteration  =  1; 

//Declares  arraye  to  store  data  points 
doublet]  sc  =  new  double  [iteration]; 
int[]  sv  =  new  int  [iteration]; 
doublet]  mt  =  new  double  [iteration]; 

//Handles  the  replication  of  the  simulation 
for  (int  i  =  0;  i  <  iteration;  i++)  { 

Schedule . reset  ( ) ; 

Schedule . startSimulation ( ) ; 
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System. out . println ( friend . getShoreCargo ( )  +  "  "  + 

friend . getSurvivability ( )  +  "  "  +  friend . getMissionTime ()) ; 

//Stores  data  values  at  completion  of  each  replication 
sc[i]  =  friend . getShoreCargo  () ; 
sv[i]  =  friend . getSurvivability ()  ; 
mt[i]  =  friend . getMissionTime ()  ; 


//Handles  writing  values  stored  in  array  to  designated  file 
Buf feredWriter  buf feredWriter  =  null; 

try  { 

//Declares  Buf feredWriter  object 

buf  feredWriter  =  new  Buf  feredWriter  (new  FileWriterCFileName.txt")) 
for  (int  i  =  0;  i  <  iteration;  i++) { 

//Start  writing  to  the  output  stream 

buf feredWriter . write ( sc [ i ]  +  "  "  +  sv[i]  +  "  "  +  mt[i]); 

buf feredWriter . newLine ( )  ; 

} 

}  catch  (Exception  e)  { 
e . printStackTrace ( )  ; 

}  finally  { 

//Closes  Buf feredWriter 
try  { 

if  (buf feredWriter  !=  null)  { 
buf feredWriter . flush ( )  ; 
buf feredWriter . close ( )  ; 

} 

}  catch  (IOException  e)  { 
e . printStackTrace ( )  ; 

} 

} 

System,  out . println ( "Complete ! " )  ; 


} 


} 
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/** 

*  SBE  Scenario 

*  Simkit  API  Source  code  in  Java  2  Platform  Standard  Ed.  5.0 

*  Authors:  LT  Ryan  Hernandez 

*  LtCOL  (HEA)  Sotiris  Papadopoulos 

*  Date:  May  2010 

*  TCraft  Class 
*/ 

package  TCraftSourceCode; 

import  j ava . awt . geom . Point2D; 
import  simkit . Schedule; 
import  simkit . random. RandomVariate; 
import  simkit . random. RandomVariateFactory; 
import  simkit . smd . BasicLinearMover; 
import  simkit . smdx . WayPoint ; 


public  class  TCraft  extends  BasicLinearMover  { 

/* 

*  State  Variables 
*/ 

//monitors  cargo  carried  on  TCraft 
protected  double  cargo; 

//monitors  damage  to  TCraft 
protected  double  damage; 

//monitors  the  amount  of  cargo  received  at  the  shore 
protected  double  shoreCargo; 

//monitors  the  survivability  rate.  Takes  values  0  (not  survive)  and  1 
(survive) 

protected  int  survivability; 

//monitors  the  status  of  the  mission.  Takes  values  0  (not  complete) 
and  1  (complete) 

protected  int  missionFlag; 

//monitors  mission  time 
protected  double  missionTime; 

//coordinates  for  all  possible  destinations  for  TCraft 
protected  static  final  WayPoint  DBK  =  new  WayPoint (new 
Point2D . Double ( -20 . 0 ,  20.0),  40.0); 

protected  static  final  WayPoint  SBO  =  new  WayPoint (new 
Point2D . Double ( 0 . 0 ,  0.0),  40.0); 

protected  static  final  WayPoint  SHO  =  new  WayPoint (new 
Point2D . Double (20 . 0 ,  -20.0),  40.0); 

//cargo  threshold  for  shore 

protected  static  final  double  SHORE_CARGO_THRESHOLD  =  1000.00; 
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//TCraft  Mover  Manager  variable 
public  TCraf tMoverManager  friendMM; 

//Declaration  of  TCraft  Waypoint  variable 
public  WayPoint  destination; 

//Declaration  of  Random  Variate  variable  for  times 
public  RandomVariate  repairTime  = 

RandomVariateFactory . get Instance ( "Exponential 15); 

public  RandomVariate  loadTime  = 

RandomVariateFactory . get Instance ( "Exponential 10 ) ; 

public  RandomVariate  unloadTime  = 

RandomVariateFactory . get Instance ( "Exponential 20 )  ; 

//Declaration  of  Random  Variate 
public  RandomVariate  cargoLoadedLow; 

//Declaration  of  Random  Variate 
public  RandomVariate  cargoLoadedHigh; 

//Declaration  of  Random  Variate 
public  RandomVariate  number; 

/* 

*  Parameters 
*/ 

//  Threshold  of  damage  recieved  for  TCraft  to  be  killed 
public  double  damageThreshold  =  0.8; 

//  Threshold  of  damage  recieved  for  TCraft  to  be  repaired 
public  double  repairThreshold  =  0.4; 

/** 

*  Constructor 

* 

*  We  assume  that  every  new  TCraft  is  initially  located  at  the 

*  debarkation  point  (DBK) 

* 

*  @param  name,  the  name  of  the  TCraft 

*  speed,  the  speed  of  the  TCraft 
*/ 

public  TCraf t ( String  name,  double  speed)  { 
super (name,  DBK . getPoint ( ) ,  speed); 

} 

/** 

*  Getter  method  for  cargo 
*/ 

public  double  getCargoO  { 
return  cargo; 

} 

/** 
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*  Getter  method  for  damage 
*/ 

public  double  getDamageO  { 
return  damage; 

} 

/*  * 

*  Getter  method  for  shoreCargo 
*/ 

public  double  getShoreCargo ( )  { 

return  shoreCargo; 

} 

/** 

*  Getter  method  for  survivability 
*/ 

public  int  getSurvivability ( )  { 

return  survivability; 

} 

/** 

*  Getter  method  for  mission  flag 
*/ 

public  int  getMissionFlag ( )  { 

return  missionFlag; 

} 

/** 

*  Getter  method  for  mission  time 
*/ 

public  double  getMissionTime ( )  { 

return  missionTime; 

} 

/** 

*  Repair  Function 

* 

*  @param  mover,  the  TCraft  to  be  repaired 

*  All  Cargo  will  be  lost  during  the  repair  process 

*  and  Damage  will  be  reset  to  0.0. 

*/ 

public  void  doRepair  (TCraft  mover)  { 

/ /Resetting  Cargo 

double  oldcargo  =  mover . getCargo () ; 
cargo  =  0.0; 

f irePropertyChange ( "cargo, "  oldcargo,  mover . getCargo ()) ; 
//Resetting  Damage 

double  olddamage  =  mover . getDamage () ; 
damage  =  0.0; 

f irePropertyChange ( "damage, "  olddamage,  mover . getDamage () ) 
waitDelay ( "Load, "  0.0,  mover); 

} 
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/** 

*  Load  Function 

* 

*  @param  mover,  the  TCraft  to  be  loaded 

*  Cargo  will  be  loaded  at  DBK  to  initialize 

*  the  TCraft  with  a  random  amount  of  cargo. 
*/ 

public  void  doLoad  (TCraft  mover)  { 


//Generation  of  random  cargo  amounts  in  one  three  distributions  at 

DBK 

//cargoLoadedLow  =  RandomVariateFactory . getlnstance ( "Uniform, "  0, 

750); 

//cargoLoadedLow  =  RandomVariateFactory . getlnstance ( "Normal , "  525, 

200)  ; 

cargoLoadedLow  =  RandomVariateFactory . getlnstance ("Exponential, " 

300)  ; 


//Finds  a  random  number  in  the  distribution 
for(int  i  =  0;  i  <  Math . random () *Math . random () ;  i++) { 
cargoLoadedLow . generate ( ) ; 

} 


//Generation  of  random  cargo  amounts  in  one  three  distributions  at 

SBO 

/ / cargoLoadedHigh  =  RandomVariateFactory . getlnstance ( "Uniform, " 

300,  750); 

//cargoLoadedHigh  =  RandomVariateFactory . getlnstance ( "Normal , "  525, 

200)  ; 

cargoLoadedHigh  =  RandomVariateFactory . getlnstance ("Exponential, " 

300)  ; 


//Finds  a  random  number  in  the  distribution 
for(int  i  =  0;  i  <  Math . random () *Math . random () ;  i++) { 
cargoLoadedHigh . generate ( ) ; 

} 

//Loading  TCraft 

if  (mover . getCurrentLocation (). equals (DBK . getPoint ()) )  { 

//Pulling  the  next  random  number  from  the  generator 
double  numericCargo  =  cargoLoadedLow . generate () ; 

//Updating  cargo  amounts 
double  old  =  mover . getCargo () ; 
cargo  =  cargo  +  numericCargo; 

f irePropertyChange ( "cargo, "  old,  mover . getCargo ()) ; 

}  else  if  (mover . getCurrentLocation (). equals ( SBO . getPoint () )  && 

(  !  (missionFlag  ==  1 ) ) )  { 

//Pulling  the  next  random  number  from  generator 
double  numericCargo  =  cargoLoadedHigh . generate (); 
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/ /Updating  cargo  amounts 
double  old  =  getCargo (); 
cargo  =  cargo  +  numericCargo; 

f irePropertyChange ( "cargo, "  old,  mover . getCargo ()) ; 

} 


/** 

*  Unload  Function 

* 

*  @param  mover,  the  TCraft  to  be  unloaded 
*/ 

public  void  doUnload  (TCraft  mover)  { 

/ /Updating  cargo  amounts 
double  old  =  mover . getCargo ()  ; 
double  oldSC  =  mover . getShoreCargo ()  ; 
shoreCargo  =  (shoreCargo  +  old) ; 
cargo  =  0.0; 

f irePropertyChange ( "shoreCargo, "  oldSC,  (mover . getShoreCargo ())); 
f irePropertyChange ( "cargo, "  old,  mover . getCargo ()) ; 

//Handles  conditions  when  shore  cargo  requirement  is  complete 
if  (mover. getShoreCargo ()  >=  SHORE_CARGO_THRESHOLD)  { 

//Updating  mission  status 

int  oldm  =  mover . getMissionFlag () ; 

missionFlag  =  1; 

f irePropertyChange ( "missionFlag, "  oldm,  mover . getMissionFlag ( ) ) ; 

} 

waitDelay ( "MoveTo, "  unloadTime,  mover); 

} 

/** 

*  End  of  Service  Function 
*/ 

public  void  doEndService (TCraft  mover)  { 

//Store  time  in  system 

double  oldTime  =  mover . getMissionTime () ; 

//Updating  mission  time  of  TCraft 

double  timelnSystem  =  Schedule . getSimTime () ; 

missionTime  =  timelnSystem; 

f irePropertyChange ( "missionTime, "  oldTime,  mover . getMissionTime ( ) ) 


//Updating  survivability  rate  of  TCraft 
int  oldSurv  =  mover . getSurvivability () ; 
survivability  =  1; 

f irePropertyChange ("survivability, "  oldSurv, 
mover . getSurvivability ( )  )  ; 

} 


229 


/** 

*  Reset  Function 
*/ 

public  void  reset  ()  { 


super . reset  ( ) ; 
cargo  =  0.0; 
damage  =  0.0; 
survivability  =  1; 
shoreCargo  =  0.0; 
missionFlag  =  0; 
missionTime  =  0.0; 


public  void  doRun(TCraft  mover)  { 

f irePropertyChange ( "cargo, "  mover . getCargo ( ) ) ; 
f irePropertyChange ("damage, "  getDamage () ) ; 
f irePropertyChange ( "survivability, "  getSurvivability ( ) ) 
f irePropertyChange ( "shoreCargo, "  getShoreCargo ( ) ) ; 
f irePropertyChange ( "missionFlag, "  getMissionFlag ( ) ) ; 

} 

} 
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/** 

*  SBE  Scenario 

*  Simkit  API  Source  code  in  Java  2  Platform  Standard  Ed.  5.0 

*  Authors:  LT  Ryan  Hernandez 

*  LtCOL  (HEA)  Sotiris  Papadopoulos 

*  Date:  May  2010 

*  TCraf tMoverManager  Class 
*/ 

package  TCraftSourceCode; 

import  j ava . awt . geom . Point2D; 
import  j ava . util . LinkedList; 
import  j ava . util . Listlterator ; 

import  simkit . Schedule; 

import  simkit . SimEntityBase; 

import  simkit . random. RandomVariate; 

import  simkit . random. RandomVariateFactory; 

import  simkit . smd . Mover ; 

import  simkit . smdx . WayPoint ; 

public  class  TCraf tMoverManager  extends  SimEntityBase  { 

/** 

*  List  of  desired  WayPoints  the  Mover  is  to  traverse 
*/ 

private  LinkedList<WayPoint>  wayPoint; 

/** 

*  Points  to  next  WayPoint  if  hasNextO  is  true. 

*/ 

protected  ListIterator<WayPoint>  nextWayPointlter ; 

/** 

*  If  true,  then  start  Mover  from  Run  event 
*/ 

private  boolean  startOnRun; 

/** 

*  The  one  Mover  this  instance  is  managing 
*/ 

private  Mover  mover; 

/** 

*  Instantiate  a  PathMoverManager  with  the  given  Mover,  WayPoints, 

*  and  whether  to  start  immediately  or  wait. 

*  @param  mover  My  Mover 

*  @param  waypoint  List  of  WayPoints  to  traverse 

*  @param  startOnRun  If  true,  start  from  Run  event 
*/ 

public  TCraf tMoverManager (TCraft  mover, 

LinkedList<WayPoint>  waypoint,  boolean  startOnRun)  { 
setMover (mover) ; 
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setWaypoint (waypoint)  ; 
setStartOnRun (startOnRun)  ; 


/** 

*  Set  nextWayPointlter  to  beginning  of  waypoint 
*/ 

public  void  reset  ()  { 

super . reset  ( ) ; 

nextWayPointlter  =  wayPoint . listlterator  () ; 


/*  * 

*  If  startOnRun  is  true,  schedule  Start. 

*/ 

public  void  doRun ( )  { 

if  ( isStartOnRun ( ) )  { 

waitDelay ( "Start, "  0.0); 

} 

} 

/** 

*  If  there  is  a  WayPoint,  schedule  StartMove (d,  s) ,  where  d  is  the 

*  location  and  s  is  the  speed  specified  by  the  WayPoint  objst. 

*/ 

public  void  doStartO  { 

nextWayPointlter  =  wayPoint . listlterator () ; 

WayPoint  next  =  nextWayPointlter . hasNext ( )  ? 

nextWayPointlter . next ( )  :  null; 

f irePropertyChange ( "nextWayPoint, "  next) ; 

if  (next  !=  null)  { 

waitDelay ( "MoveTo, "  0.0,  next . getPoint ( ) ,  next . getSpeed ( ) ) ; 

} 


/** 

*  Empty  -  to  be  heard. 

*  @param  destination  desired  destination 

*  @param  speed  desired  speed 
*/ 

public  void  doMoveTo ( Point2D  destination,  double  speed)  { 

} 

/** 

*  Heard  from  mover.  If  there  is  another  WayPoint,  schedule 

*  MoveTo  (d,s)  for  it;  otherwise,  schedule  OrderStop (mover ) . 

*  @param  mover  My  mover 
*/ 

public  void  doEndMove (TCraft  mover)  { 

RandomVariate  moveTime  = 

RandomVariateFactory . getlnstance ( "Exponential , "  1) ; 

WayPoint  next  =  nextWayPointlter . hasNext  ( )  ? 

nextWayPointlter . next ( )  :  null; 
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f irePropertyChange ( "nextWayPoint, "  next) ; 
if  (next  !=  null)  { 

//Handles  status  of  TCraft  and  scheduling  events 
if  (mover . getCurrentLocation (). equals (TCraft . SBO . getPoint () )  && 
mover . getMissionFlag ( )  ==  0  && 

mover . getDamage ( )  >=  mover . repairThreshold)  { 
waitDelay ( "Repair , "  0.0,  mover); 

} 

if  ( ( ! mover . getCurrentLocation ( ) . equals (TCraft . SHO . getPoint ()) )  && 

mover . getMissionFlag ( )  ==  0  && 
mover . getDamage ( )  <  mover . repairThreshold  && 
mover . getCargo ( )  <=  300)  { 

waitDelay ( "Load, "  0.0,  mover); 

} 

if  (mover . getCurrentLocation (). equals (TCraft . SHO . getPoint () )  && 

mover . getMissionFlag ( )  ==  0)  { 

waitDelay ( "Unload, "  0.0,  mover); 

} 

waitDelay ( "MoveTo, "  moveTime,  next . getPoint () ,  next . getSpeed ( ) ) ; 

if  ( ( ! (mover . getCurrentLocation ( ) . equals (TCraft . DBK . getPoint ( ) ) ) ) 
&&  mover . getMissionFlag ( )  ==  1)  { 

waitDelay ( "EndService, "  0.0,  mover); 

} 

} 

if  (next  ==  null)  { 

//Store  time  in  system 

double  oldTime  =  mover . getMissionTime () ; 

//Updating  mission  time  of  TCraft 

double  timelnSystem  =  Schedule . getSimTime () ; 

mover .missionTime  =  timelnSystem; 

f irePropertyChange ( "missionTime, "  oldTime,  mover . getMissionTime ( ) ) 

waitDelay ( "OrderStop, "  0.0,  mover); 

} 


/** 

*  Schedule  OrderStop (mover ) . 

*/ 

public  void  doStopO  { 

//System. out . print In ( "OrderStop" ) ; 


233 


waitDelay ( "OrderStop, "  0.0,  mover); 

} 

/** 

*  @return  the  list  of  WayPoints  (shallow  copy) 

*/ 

public  LinkedList<WayPoint>  getWaypoint ( )  { 

return  new  LinkedList<WayPoint> (wayPoint) ; 

} 

/** 

*  @param  wayPoint  the  wayPoint  to  set 
*/ 

public  void  setWaypoint (LinkedList<WayPoint>  waypoint)  { 
this . wayPoint  =  new  LinkedList<WayPoint> (waypoint) ; 

} 

/** 

*  If  true,  start  moving  at  beginning  of  simulation 

*  @return  the  startOnRun 
*/ 

public  boolean  isStartOnRun ( )  { 

return  startOnRun; 

} 

/** 

*  @param  startOnRun  the  startOnRun  to  set 
*/ 

public  void  setStartOnRun (boolean  startOnRun)  { 
this . startOnRun  =  startOnRun; 

} 

/** 

*  @return  the  mover 
*/ 

public  Mover  getMover()  { 
return  mover; 

} 

/** 

*  @param  mover  the  mover  to  set 
*/ 

public  void  setMover (TCraft  mover)  { 

if  (this. mover  !=  null)  { 

this . mover . removeSimEvent Listener ( this ) ; 
this . removeSimEventListener (this .mover) ; 

} 

this. mover  =  mover; 

this . mover . addSimEvent Listener ( this ) ; 
this . addSimEventListener (this .mover) ; 

} 
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/** 

*  @return  the  nextWayPointlter 
*/ 

public  ListIterator<WayPoint>  getNextWayPointlter ( )  { 

return  nextWayPointlter; 

} 

/** 

*  @return  next  WayPoint  or  null  if  none 
*/ 

public  WayPoint  getNextWayPoint ( )  { 

int  index  =  nextWayPointlter . nextlndex () ; 
if  (index  <  wayPoint . size () )  { 

return  wayPoint . get ( index) ; 

}  else  { 

return  null; 

} 

} 

} 
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/** 

*  SBE  Scenario 

*  Simkit  API  Source  code  in  Java  2  Platform  Standard  Ed.  5.0 

*  Authors:  LT  Ryan  Hernandez 

*  LtCOL  (HEA)  Sotiris  Papadopoulos 

*  Date:  May  2010 

*  TCraf tMediator  Class 
*/ 

package  TCraftSourceCode; 

import  simkit . SimEntityBase; 

import  simkit . smd . Coo kieCut ter Sensor; 

import  simkit . smd . SensorMoverMediator ; 

/** 

*  Simple  Mediator.  Schedules  Detections  and  Undetections. 

*  (Aversion  $Id:  CookieCutterMediator  .  j  ava 

*  @author  Professor  Arnold  Buss  @  NPS 
*/ 

public  class  TCraf tMediator  extends  SimEntityBase  implements 
SensorMoverMediatorkTCraf t ,  Coo kieCut ter Sens or > { 

/** 

*  Schedule  Detection (mover)  on  sensor  with  delay  of  0.0  if  the 

*  sensor  hasn't  already  detected  the  target. 

*  @param  mover  The  target 

*  @param  sensor  The  Sensor 
*/ 

public  void  doEnterRange (TCraft  mover,  CookieCutterSensor  sensor)  { 

if  (! sensor . getContacts (). contains (mover ) )  { 

sensor . waitDelay ( "Detection, "  0.0,  mover); 

} 

} 

/** 

*  Schedule  Undetection (mover )  with  delay  of  0.0. 

*  @param  mover  The  target 

*  @param  sensor  The  Sensor 
*/ 

public  void  doExitRange (TCraft  mover,  CookieCutterSensor  sensor)  { 
sensor .waitDelay ("Undetection, "  0.0,  mover); 

} 
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/** 

*  SBE  Scenario 

*  Simkit  API  Source  code  in  Java  2  Platform  Standard  Ed.  5.0 

*  Authors:  LT  Ryan  Hernandez 

*  LtCOL  (HEA)  Sotiris  Papadopoulos 

*  Date:  May  2010 

*  HostileSensor  Class 
*/ 

package  TCraftSourceCode; 
import  simkit . SimEntityBase; 

public  class  HostileSensor  extends  SimEntityBase  { 

public  void  doDetection (TCraft  mover)  { 

//When  TCraft  is  detected,  an  Attack  event  is  scheduled 
if  (mover . getName ( )  ==  "TCraft")  { 
waitDelay ( "Attack, "  0.0,  mover); 

} 

} 


} 
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/** 

*  SBE  Scenario 

*  Simkit  API  Source  code  in  Java  2  Platform  Standard  Ed.  5.0 

*  Authors:  LT  Ryan  Hernandez 

*  LtCOL  (HEA)  Sotiris  Papadopoulos 

*  Date:  May  2010 

*  Adjudicator  Class 
*/ 

package  TCraftSourceCode; 
import  simkit . Schedule; 


public  class  Adjudicator  extends  HostileSensor  { 

public  void  doAttack (TCraft  mover)  { 
waitDelay ( "BDA, "  0.0,  mover); 

} 

public  void  doBDA (TCraft  mover)  { 

//generates  random  damage  amount 
double  damage  =  Math . random () ; 

/ /Updating  damage 

double  old  =  mover . getDamage () ; 

mover. damage  =  mover. damage  +  damage; 

f irePropertyChange ( "damage, "  old,  mover . getDamage ()) ; 
if  (mover . damage  >  mover . damageThreshold)  { 
waitDelay ( "Killed, "  0.0,  mover); 

//Store  time  in  system 

double  oldTime  =  mover . getMissionTime () ; 

//Updating  mission  time  of  TCraft 
double  timelnSystem  =  Schedule . getSimTime () ; 
mover .missionTime  =  timelnSystem; 
f irePropertyChange ("missionTime, "  oldTime, 
mover . getMissionTime ( ) ) ; 

} 

} 

public  void  doKilled (TCraft  mover)  { 

//Updating  survivability 
mover . survivability  =  0; 

Schedule . stopSimulation ( ) ; 

} 

} 
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